NAT'L  INST   OF  STAND  S  TECH 


AlllDt.  '^7flM0S 

of  Commerce 

NBS 
PUBLICATIONS 


National  Bureau 
of  Standards 


'"St. 


Computer  Science 
and  Technology 


NBS  Special  Publication  500-91 

The  Introduction 
of  Software  Tools 


NATIONAL  BUREAU  OF  STANDARDS 

The  National  Bureau  of  Standards'  was  established  by  an  act  of  Congress  on  March  3,  1901. 
The  Bureau's  overall  goal  is  to  strengthen  and  advance  the  Nation's  science  and  technology 
and  facilitate  their  effective  application  for  public  benefit.  To  this  end,  the  Bureau  conducts 
research  and  provides:  (1)  a  basis  for  the  Nation's  physical  measurement  system,  (2)  scientific 
and  technological  services  for  industry  and  government,  (3)  a  technical  basis  for  equity  in 
trade,  and  (4)  technical  services  to  promote  public  safety.  The  Bureau's  technical  work  is  per- 
formed by  the  National  Measurement  Laboratory,  the  National  Engineering  Laboratory,  and 
the  Institute  for  Computer  Sciences  and  Technology. 

THE  NATIONAL  MEASUREMENT  LABORATORY  provides  the  national  system  of 
physical  and  chemical  and  materials  measurement;  coordinates  the  system  with  measurement 
systems  of  other  nations  and  furnishes  essentia!  services  leading  to  accurate  and  uniform 
physical  and  chemical  measurement  throughout  the  Nation's  scientific  community,  industry, 
and  commerce;  conducts  materials  research  leading  to  improved  methods  of  measurement, 
standards,  and  data  on  the  properties  of  materials  needed  by  industry,  commerce,  educational 
institutions,  and  Government;  provides  advisory  and  research  services  to  other  Government 
agencies;  develops,  produces,  and  distributes  Standard  Reference  Materials;  and  provides 
calibration  services.  The  Laboratory  consists  of  the  following  centers: 

Absolute  Physical  Quantities^  —  Radiation  Research  —  Chemical  Physics  — 
Analytical  Chemistry  —  Materials  Science 

THE  NATIONAL  ENGINEERING  LABORATORY  provides  technology  and  technical  ser- 
vices to  the  public  and  private  sectors  to  address  national  needs  and  to  solve  national 
problems;  conducts  research  in  engineering  and  applied  science  in  support  of  these  efforts; 
builds  and  maintains  competence  in  the  necessary  disciplines  required  to  carry  out  this 
research  and  technical  service;  develops  engineering  data  and  measurement  capabilities; 
provides  engineering  measurement  traceability  services;  develops  test  methods  and  proposes 
engineering  standards  and  code  changes;  develops  and  proposes  new  engineering  practices; 
and  develops  and  improves  mechanisms  to  transfer  results  of  its  research  to  the  ultimate  user. 
The  Laboratory  consists  of  the  following  centers: 

Applied  Mathematics  —  Electronics  and  Electrical  Engineering^  —  Manufacturing 
Engineering  —  Building  Technology  —  Fire  Research  —  Chemical  Engineering^ 

THE  INSTITUTE  FOR  COMPUTER  SCIENCES  AND  TECHNOLOGY  conducts 
research  and  provides  scientific  and  technical  services  to  aid  Federal  agencies  in  the  selection, 
acquisition,  application,  and  use  of  computer  technology  to  improve  effectiveness  and 
economy  in  Government  operations  in  accordance  with  Public  Law  89-306  (40  U.S.C.  759), 
relevant  Executive  Orders,  and  other  directives;  carries  out  this  mission  by  managing  the 
Federal  Information  Processing  Standards  Program,  developing  Federal  ADP  standards 
guidelines,  and  managing  Federal  participation  in  ADP  voluntary  standardization  activities; 
provides  scientific  and  technological  advisory  services  and  assistance  to  Federal  agencies;  and 
provides  the  technical  foundation  for  computer-related  policies  of  the  Federal  Government. 
The  Institute  consists  of  the  following  centers: 

Programming  Science  and  Technology  —  Computer  Systems  Engineering. 

'Headquarters  and  Laboratories  at  Gaithersburg,  MD,  unless  otherwise  noted; 
mailing  address  Washington,  DC  20234. 

'Some  divisions  within  the  center  are  located  at  Boulder,  CO  80303. 


or  trtAmAMim 


SEP  Z  0  1982 


Computer  Science 
and  Technology 


NBS  Special  Publication  500-91 


The  Introduction 
of  Software  Tools 


U.S.  DEPARTMENT  OF  COMMERCE 

Malcolm  Baldrige,  Secretary 

National  Bureau  of  Standards 

Ernest  Ambler,  Director 

Issued  September  1982 


Herbert  Hecht 


SoHaR  Incorporated 
1040  So.  La  Jolla  Avenue 
Los  Angeles,  California  90035 


Reports  on  Computer  Science  and  Technology 

The  National  Bureau  of  Standards  has  a  special  responsibility  within  the  Federal 
Government  for  computer  science  and  technology  activities.  The  programs  of  the 
NBS  Institute  for  Computer  Sciences  and  Technology  are  designed  to  provide  ADP 
standards,  guidelines,  and  technical  advisory  services  to  improve  the  effectiveness 
of  computer  utilization  in  the  Federal  sector,  and  to  perform  appropriate  research 
and  development  efforts  as  foundation  for  such  activities  and  programs.  This 
publication  series  will  report  these  NBS  efforts  to  the  Federal  computer  community  as 
well  as  to  interested  specialists  in  the  academic  and  private  sectors.  Those  wishing 
to  receive  notices  of  publications  in  this  series  should  complete  and  return  the  form 
at  the  end  of  this  publication. 


National  Bureau  of  Standards  Special  Publication  500-91 
Natl.  Bur.  Stand.  (U.S.),  Spec.  Publ.  500-91,  41  pages  (Sept.  1982) 

CODEN:  XNBSAV 

Library  of  Congress  Catalog  Card  Number:  82-600577 


U.S.  GOVERNMENT  PRINTING  OFFICE 
WASHINGTON:  1982 


For  sale  by  the  Superintendent  of  Documents,  U.S.  Government  Printing  Office,  Washington,  D.C.  20402 

Price  $4.75 
(Add  25  percent  for  other  than  U.S.  mailing) 


ABSTRACT 


From  a  survey  of  current  tool  usage  It  Is  concluded  that  the  greatest 
obstacles  to  effective  use  of  software  tools  are  encountered  In 
organizations  employing  fewer  than  40  programmers ,  and  the  needs  of 
these  environments  are  therefore  emphasized.  Specific  needs  for 
software  tools  In  programming  for  management  Information  systems  and 
for  scientific  applications  are  discussed.  Measures  are  described  to 
overcome  organizational  obstacles  to  use  of  tools,  to  deal  with 
problems  arising  from  the  tools,  and  to  reduce  the  difficulties  posed 
by  existing  computer  Installations. 

Steps  required  for  the  successful  Introduction  of  tools  are  organized 
In  two  ways:  by  the  function  responsible  for  their  accomplishment,  and 
by  the  time  schedule  In  which  they  must  be  completed.  The  detail  work 
to  be  performed  In  each  step  Is  described. 


Key  words:  computer  environments;  software;  software  engineering; 
software  management;  software  quality;  software  tools;  tool  smith. 
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EXECUTIVE  SUMMARY 


This  publication  Is  Intended  to  provide  guidance  for  the  Introduction  of 
software  tools  for  agencies  of  the  U.  S.  Government  and  for  computer  users  at 
large.  It  Is  primarily  aimed  at  installations  where  there  had  been  little  or  no 
use  of  software  tools  previously.  In  a  survey  of  software  tool  usage  it  was 
found  that  the  size  of  the  programming  group  had  a  significant  effect  on  the 
extent  of  tool  usage,  with  organizations  of  less  than  40  programmers  much  less 
likely  to  be  tools  users.  To  provide  help  to  these  smaller  organizations  In  the 
Introduction  and  use  of  software  tools  Is  therefore  one  of  the  goals  of  this 
document. 

Difficulties  in  the  Introduction  of  tools  can  arise  In  three  areas: 

Organizational  obstacles. 
Problems  arising  from  the  tools. 
Obstacles  in  the  computer  environment. 

Organizational  obstacles  can  be  reduced  If  a  responsible  management  level  is 
Involved  in  the  Introduction  of  tools.  Those  who  commit  the  resources  for  tool 
acquisition  and  use  should  participate  actively  in  the  relevant  decisions. 
Their  involvement  in  the  following  is  particularly  Important: 

1.  Identifying  the  goals  to  be  met  by  the  tool  (or  by  the  technique  supported 
by  the  tool),  and  assigning  responsibility  for  the  activities  required  to 
meet  these  goals. 

2.  Approving  a  detailed  tool  acquisition  plan  that  defines  the  resource 
requirements  for  procurement  and  In-house  activities. 

3.  Approving  procurement  of  tools  and  training  If  this  Is  not  explicit  In  the 
approval  of  the  acquisition  plan. 

4.  Determining  after  some  period  of  tool  use  whether  the  goals  have  been  met. 

Prob  I  ems  ar  I  s  I  ng  from  the  too  I  s  can  be  avoided  by  a  careful,  methodical 
selection  of  tools.     In  particular,  distinct  contributions  to  the  tool  selection 
are  specified  for  software  management  and  the  software  engineer.  Software 
management  Is  assigned  responsibility  for: 
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1.  Identifying  tool  objectives. 

2.  Approving  the  acquisition  plan  (higher  approvals  may  also  be  required). 

3.  Defining  selection  criteria, 

4.  Making  the  final  selection  of  the  tool  or  the  source. 
The  software  engineer  Is  responsible  for: 

1.  Identifying  candidate  tools. 

2.  Applying  the  selection  criteria  or  preparing  technical  sections  for 
a  Request  for  Proposals  (RFP). 

3.  Preparing  a  ranked  list  of  tools  or  sources. 

Further,  the  ultimate  user  of  the  tool  should  be  Involved  In  reviewing  either 
the  list  of  candidate  tools  or,  for  formal  procurement,  the  tool  requirements. 

Obstacles  In  the  computer  environment  are  primar 1 1 y  due  to  the  great  d I  vers  I  ty 
of  computer  architectures  and  operating  system  procedures,  and  to  the  lack  of 
portability  of  most  software  tools.  Activities  associated  with  the  Introduction 
of  tools  can  only  modestly  alleviate  these  difficulties.  Guidance  Is  provided 
for: 

1.  A  methodical  process  of  Identifying  candidate  tools  and  selecting  among 
these  on  the  basis  of  established  criteria.  Including  a  definition  of  the 
computer  Interface.  This  will  avoid  some  of  the  worst  pitfalls  associated 
with  "borrowing"  a  tool  from  an  acquaintance  or  procuring  one  from  the  most 
accessible  tool  vendor. 

2.  The  assignment  and  training  of  a  toolsmlth  who  can  make  minor  modifications 
to  both  the  computer  environment  and  the  tool.  This  Is  expected  to  provide 
relief  where  there  are  version-related  or  release-related  Incompatibilities 
with  the  operating  system,  or  where  the  memory  requirements  of  the  tool 
exceed  the  capabilities  of  the  Installation.  In  the  latter  case,  remedies 
may  be  provided  by  removing  tool  options  or  by  structuring  the  tool  program 
I nto  over  I  ays. 

As  part  of  this  work,  an  event  sequence  for  the  Introduction  of  tools  has  been 
developed  that  Identifies  specific  tasks,  the  assignment  of  responsibilities  for 
the  tasks,  and  the  order  In  which  they  have  to  be  carried  out. 
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SECTION  2 
IMTRODUCTION 


This  publication  Is  intended  to  provide  guidance  for  the  Introduction  of 
software  tools  for  agencies  of  the  U.  S.  Government  and  for  computer  users  at 
large.  It  is  primarily  aimed  at  installations  where  there  had  been  little  or  no 
use  of  software  tools  previously.  In  a  survey  of  software  tool  usage  it  was 
found  that  the  size  of  the  programming  group  had  a  significant  effect  on  the 
extent  of  tool  usage,  with  organizations  of  less  than  40  programmers  much  less 
likely  to  be  tools  users  LhECHSIH.  In  particular,  organizations  of  less  than  40 
programmers  were  found  to  need  help  In  order  to  acquire  and  employ  software 
software  tools  successfully,  and  the  requirements  of  these  organizations  are 
given  special  emphasis. 

Many  of  the  difficulties  reported  by  novice  users  with  software  tools  can  be 
overcome  by  systematic  practices  in  the  selection,  acquisition,  and  preparation 
for  use  of  software  tools.  This  report  first  derives  the  need  for  specific 
guidance  In  the  introduction  of  tools  by  examining  a  number  of  programming 
environments,  and  then  describes  the  practices  suited  to  these  environments. 

Section  3  charaterlzes  user  environments  In  terms  significant  for  the 
introduction  of  software  tools.  In  this  characterization,  two  environments  were 
Identified  that  will  benefit  most  from  formal  guidance  for  the  Introduction  of 
tools,  and  a  vignette  of  each  of  these  Is  presented  In  the  final  parts  of 
Section  3, 

Tool  needs  for  various  user  environments  are  described  In  Section  4.  First,  a 
fairly  broad  discussion  of  organizational  and  application  factors  that  govern 
tool  needs  Is  presented.  Then,  based  on  these  considerations,  a  generic 
(features  based)  Identification  of  tool  needs  for  the  two  target  environments  Is 
made.  Needs  of  other  environments  are  also  discussed,  and  special  attention  Is 
focused  on  the  Integration  of  tools.  The  final  part  of  Section  4  covers 
resources  for  the  selection  of  tools.  The  recent  publication  of  a  report  on 
software  development  tools  by  NBS/ICST  Is  of  major  assistance  in  this  area 
LH0UG82I].  The  generic  software  tool  nomenclature  used  In  the  present  report  Is 
taken  from  LH0UG81I]  which  in  turn  incorporates  major  portions  of  a  Software  Tool 
Taxonomy  [REIF80J. 

The  time  phasing  aspect  of  the  introduction  of  tools  is  described  In  Section  5 
by  means  of  event  sequences.  The  purpose  of  event  sequences  Is  discussed  in 
general  terms,  and  the  specific  event  sequence  for  the  introduction  of  software 
tools  Into  the  smaller  programming  environments  Is  then  developed.  The  events 
are  classified  by  area  of  responsibility  and  precedence  relationships,  and  each 
of  the  required  events  Is  described  in  detail. 

A  preliminary  draft  of  this  document  was  discussed  at  a  Workshop  on  Phasing  of 
Software  Tools  which  was  held  at  NBS  on  18  May  1981.  The  agenda  and  the 
attendance  list  are  reproduced  In  the  Appendix.    The  participants  contributed 
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many  constructive  comments  which  have  been  Incorporated  Into  the  present 
version.  Written  comments  were  received  from  several  Individuals  who  could  not 
attend  the  workshop;  these  contributors  have  been  listed  as  "reviewers"  in  the 
Appendix, 

The  author  wishes  to  acknowledge  the  contributions  of  collaborators  in  the 
preparation  of  this  document.  Myron  Hecht  analyzed  the  survey  results  which 
form  the  basis  for  Section  3,  and  Donald  J,  Reifer  classified  tool  needs  as 
reported  in  Section  4.  Much  helpful  guidance  In  the  conduct  of  this  study  was 
received  from  the  technical  monitor  for  the  contract,  Mr.  R.  C.  Houghton,  Jr. 
Continued  encouragement  and  many  helpful  suggestions  were  furnished  by  Dr. 
Martha  Branstad,  the  ICST  Software  Quality  Program  Manager. 
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SECTION  3 

CHARACTERIZATION  OF  USER  ENVIRONIErfTS 


This  section  considers  the  characterization  of  user  environments  along  lines 
that  are  significant  for  the  Introduction  of  software  tools.  The  starting  point 
for  this  characterization  Is  the  classification  of  software  tool  users  which  Is 
summarized  In  subsection  3.1.  The  selection  of  target  environments  for  the 
Introduction  of  software  tools,  based  on  this  classification.  Is  described  In 
subsection  3.2.  The  smaller  classes  of  management  Information  system  (MIS)  and 
scientific  programming  environments  are  Identified  as  most  In  need  of  outside 
assistance  In  tool  usage,  and  vignettes  typical  of  each  of  these  environments 
are  presented  In  subsections  3.3  and  3.4,  respectively. 


3.1    CLASSIFICATION  OF  ENVIRONMENTS 

A  Survey  of  Software  Tools  Usage  ChECHSO  considers  the  effect  on  tool  usage  of 
a  fairly  large  number  of  environmental  factors.  Including: 

Size  of  software  organization. 

Type  of  organization  (private.  Government-support,  Government). 

Applications  (scientific,  MIS)  and  language. 

Development  environment  (batch.  Interactive). 

Program  running  environment  (batch.  Interactive,  real-time). 

Computer  type. 

Involvement  In  tool  development. 

The  first  and  last  factors  were  found  to  have  a  significant  effect  on  the  extent 
of  tool  usage.  The  type  of  organization  was  not  found  to  be  a  major  determinant 
of  the  extent  of  tool  usage  In  this  survey.  The  other  factors  had  some  effect 
on  the  types  of  tools  that  were  used  but  not  on  the  extent  of  tool  usage  (or  the 
effect  was  masked  by  correlation  with  primary  determinants  of  tool  usage). 

In  the  following  discussion  the  extent  of  tool  usage  Is  classified  Into  three 
I  eve I s : 

Level  0  Minimal  tool  usage  -  only  tools  normally  provided  with  the  operating 
system  were  In  use  (assemblers-  loaders,  compilers,  debug  aids,  and 
I nterpreters) . 

Level  1  Intermediate  tool  usage  -  special  purpose  tools  suited  for  the  mission 
of  the  organization  but  without  explicit  effect  on  software  quality 
were  In  use.  Examples  are  simulators,  file  managers,  and  elementary 
precomp 1 1 ers. 
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Level  2  General  purpose  tool  usage  -  general  purpose  tools.  Involving  static 
and  dynamic  analysis  features,  were  deliberately  acquired  or  developed 
In  order  to  enhance  software  quality  and  productivity.  This  group 
represents  the  highest  level  of  tool  utilization  identified  In  the 
survey. 

By  Interpreting  the  level  Index  (0,  1,  or  2)  as  a  number,  an  average  level  of 
tool  utilization  can  be  computed  for  groups  of  tool  users.  The  average  level  of 
tool  utilization  as  affected  by  the  size  of  the  organization  Is  shown  In  Table 
3-1 . 


TABLE  3  -  1     LEVEL  OF  TOOL  UTILIZATION 

Size  of  Organization  Avg,  Level  of 

Tool  UtI I Izatlon 


Smal 1  -  up  to  14  programmers 

0.8 

Medium  -  15  to  39  programmers 

0.8 

Large  -  40  to  99  programmers 

1 .4 

Very  large  -  over  100  programmers 

2.0 

The  term  progranmer  Includes  analysts,  programming  supervisors,  and  programming 
trainees  but  not  computer  operators,  librarians,  or  other  support  personnel. 
The  above  data  are  based  on  a  survey  of  22  organizations.  Tool  developers  were 
not  Included  in  this  population. 


3.2    SELECTION  OF  TARGET  ENVIRONMENTS 

As  can  be  seen  from  Table  3-1,  the  use  of  general  purpose  software  tools  was 
considerably  less  prevalent  among  small  and  medium  software  organizations  than 
among  the  large  and  very  large  organizations.  In  all  size  classifications  there 
was  representation  of  private.  Government,  and  Government-support  organizations 
(the  three  classifications  for  type  of  organization  considered  In  this  study). 
No  evidence  was  found  that  the  organization  type  affecrs  the  level  of  tool 
usage,  but  because  of  the  small  sample  size  this  Is  regarded  as  only  a  tentative 
cone  I  us  Ion. 

These  data  indicate  that  small  and  medium  software  organizations  will  represent 
the  target  environment  that  stands  to  benefit  most  from  the  availability  of  a 
comprehensive  methodology  for  the  Introduction  of  software  tools.  In  addition 
to  the  low  level  of  current  tool  usage  shown  in  Table  3-1,  the  following  facTors 
Indicate  that  small  and  medium  organizations  need  outside  assistance  In  the 
Introduction  of  tools: 

1.  Their  awareness  of  tools  In  general,  and  their  knowledge  about  specific 
tools  suited  to  their  needs,  are  frequently  much  less  than  that  of  larger 
organizations. 
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2.  Their  knowledge  of  tool  acquisition  and  Installation  practices  tends  to  be 
Inadequate  to  permit  them  to  obtain  the  full  benefit  from  available  tools. 

3.  Even  when  suitable  tools  are  obtained  and  Installed,  these  organizations 
frequently  cannot  mobilize  the  resources  required  for  optimum  tool 
utilization,  such  as  training,  start-up  efforts,  and  change  In  practices  to 
f ul ly  uti I Ize  a  tool , 

A  further  consideration  (which  partly  encompasses  all  of  the  above)  Is  that  a 
given  level  for  effort  In  developing  a  methodology  for  the  Introduction  of  tools 
can  be  expected  to  provide  much  more  significant  and  measurable  results  If  that 
effort  Is  targeted  at  organizations  at  the  smaller  end  of  the  size  range. 

The  above  does  not  Imply  that  large,  and  even  very  large,  organizations  cannot 
benefit  from  further  developments  of  methodology  for  the  Introduction  of 
software  tools,  and  specifically  from  efforts  In  that  area  undertaken  by 
NBS/ICST.  The  needs  of  these  environments  are  further  addressed  In  subsection 
4.3  of  this  report. 

The  need  for  outside  assistance  for  the  development  of  a  suitable  Introduction 
methodology  Is  shared  by  small  and  medium  size  organizations.  There  are  only 
minor  differences  In  the  details  of  the  application  of  the  methodology  between 
small  and  medium  size  organizations,  and  to  avoid  long  titles  the  term  "smaller" 
will  henceforth  designate  the  two  groups  collectively.  Within  the  smaller  size 
groups,  the  Introduction  methodology  will  focus  on  Government  organizations 
although,  as  will  be  explained  shortly,  most  of  the  Introductory  practices  are 
not  expected  to  vary  significantly  as  a  function  of  the  organization  type.  The 
reasons  for  focusing  on  Government  organizations  are: 

1,  The  demand  for  uniformity  of  software  practices  In  Government  agencies  Is 
expected  to  Increase,  and  tools  can  be  of  assistance  In  providing  and 
enforcing  this  uniformity.  Hence,  a  greater  need  for  tools  Is  expected  to 
arise  In  this  environment. 

2,  Government  agencies  usually  have  a  greater  need  to  control  procedural 
aspects  of  software  development,  and  many  tools  address  that  need  very 
specif  leal ly. 

3,  There  are  a  large  number  of  tools  currently  In  Government  Inventory,  and 
some  of  these  are  resident  on  computers  that  can  be  accessed  by  other 
Government  organizations  via  terminals.  Experience  with  tools  may  be 
shared,  and  help  with  tool  problems  may  be  furnished  more  readily  among 
Government  agencies  than  within  the  private  sector  or  between  Government 
and  private  organizations.  Thus,  the  opportunity  for  tool  usage  Is  greater 
among  Government  organizations. 

4,  Successful  use  of  a  tool  In  a  Government  organization  Is  likely  to  become 
generally  known  (via  professional  organizations,  computer  user  groups, 
etc.)  whereas  smaller  private  organizations  may  wish  to  restrict  the 
dissemination  of  this  Information  for  competitive  reasons.  Thus,  the 
ripple  effect  can  be  expected  to  be  greater  If  Government  organizations  are 
addressed  as  the  primary  target  for  the  tool  Introduction  methodology. 
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Except  for  the  factors  mentioned  above,  the  activities  and  level  of  effort 
required  for  the  Introduction  of  tools  are  not  believed  to  be  significantly 
different  among  private.  Government-support,  and  Government  organizations.  The 
greater  availability  of  tools  may  appear  to  confer  a  material  advantage  on 
Government  organizations  but  at  present  this  has  not  been  a  cause  for  Increased 
usage.  The  annual  licensing  fee  for  a  typical  tool  Is  of  the  order  of  $  1,000, 
and  purchasing  costs  are  five  to  ten  times  that  amount.  These  are  usually  not 
the  dominant  expenses  In  the  Introduction  of  a  software  tool.  A  large  number  of 
tools  are  In  the  public  domain  and  copies  can  be  obtained  at  nominal  cost  from 
computer  vendors,  universities,  and  some  organizations  which  specialize  In  this 
field.  Thus,  although  the  terminology  used  In  the  following  may  be  specific  to 
Government  organizations,  the  general  concepts  are  believed  to  be  broadly 
appi Icable. 

Among  the  smaller  Government  organizations,  the  survey  found  differences  In 
tool  needs  that  Indicate  that  administrative  and  scientific  environments  may 
best  be  treated  separately  for  some  aspects  of  the  Introduction  of  software 
tools.  A  demonstrable  difference  Is  In  the  types  of  tools  needed  (In  turn 
dictated  by  the  languages  used):  the  most  widely  encountered  tool  In  smaller 
scientific  organizations  Is  a  FORTRAN  preprocessor,  whereas  COBOL  environments 
frequently  use  optimization  tools  that  have  no  direct  counterparts  In  the 
scientific  environments,  A  more  subtle  difference  exists  In  the  overall 
attitude  towards  tools.  Scientific  programmers  (specifically  engineers  and 
scientists  doubling  as  programmers)  know  about  tools  and  may  be  conscious  of 
some  of  the  advantages  that  they  confer,  but  are  Interested  primarily  (sometimes 
exclusively)  In  solving  scientific  or  englneeering  problems.  They  are  only 
slightly  motivated  to  devote  any  effort  toward  the  enhancement  of  software 
quality.  Programmers  and  first  level  supervision  In  the  smaller  administrative 
or  MIS  (Management  Information  Systems)  environment  may  be  only  vaguely  aware  of 
tools  but  are  highly  motivated  to  Improve  the  quality  of  their  software, 
particularly  Its  mal ntal nabl I Ity. 

The  following  subsections  provide  vignettes  of  the  smaller  MIS  and  scientific 
environments,  respectively,  that  particularly  emphasize  factors  pertinent  in  the 
Introduction  of  tools. 


3.3    THE  SMALLER  MIS  ENVIRONMENT 

The  term  MIS  environment  Is  Intended  to  Include  all  programming  for  fiscal, 
administrative,  housekeeping,  and  record-keeping  functions.  The  predominant 
language  Is  COBOL  but  a  fair  amount  of  assembly  language  programming  (In 
application  programs)  Is  also  In  use.  ALGOL  and  PL/1  are  used  occasionally  In  a 
few  agencies.  Practically  all  system  programs  used  by  the  smaller  MIS 
organizations  are  written  In  assembly  language. 

By  our  definition,  a  smaller  organization  may  Include  up  to  39  programmers,  but 
the  representative  Government  organization  In  this  category  rarely  involves  more 
than  25  or  30  programmers.  It  is  typically  a  field  office  or  a  central 
programming  organization  for  a  specialized  agency  or  function  within  an  agency. 
There  are  two  levels  of  supervision.    The  lower  one  deals  with  a  specific 
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programming  area  (systems,  disbursals,  security,  etc.)  while  the  major 
responsibility  of  the  upper  supervisor  Is  to  maintain  liaison  with  the 
headquarters  organization  which  generates  the  requirements  and  funding  for  the 
office.  Very  few.  If  any,  of  the  smaller  Government  MIS  organizations  can  make 
It  a  major  assignment  for  one  of  their  employees  to  provide  guidance  In  software 
technology  and  programming  practices.  Some  of  this  guidance  might  be  provided 
by  headquarters  organizations,  and  thus  will  be  relayed  through  the  highest 
supervisory  level.  But  without  a  specific  local  designee  who  provides 
follow-up,  much  of  the  Impact  of  headquarter  guidance  will  be  lost. 

The  range  of  programmer  skill  levels  encountered  In  MIS  organizations  Is  broader 
than  that  prevalent  In  scientific  environments,  primarily  due  to  the  use  of 
programmer  trainees  by  the  MIS  organizations.  The  formal  training  of  the 
programming  trainees  consists  of  In-house  courses,  technical  school  courses,  and 
approximately  1  year  of  attendance  at  a  community  college.  They  are  trained  for 
program  writing  rather  than  software  design  or  broader  aspects  of  computer 
science  or  software  engineering.  There  Is  also  little  Involvement  In  standards 
or  professional  activities  among  the  MIS  organizations.  Indicating  few 
opportunities  for  a  continuing,  broadening  education  of  the  programmers  In  this 
envl ronment. 

The  primary  activity  of  the  smaller  MIS  organizations  frequently  Is  program 
maintenance.    The  programs  undergo  almost  constant  change  due  to: 

Changes  In  legislation. 

Changes  In  administrative  procedures. 

Major  organizational  restructuring. 

Program  or  functional  Improvement. 

Correction  of  errors. 

Offices  have  backlogs  that  range  up  to  1  year.  Maintenance  Is  a  slow  and 
difficult  process  because  of  the  lack  of  good  documentation  (a  facxor  that 
transcends  this  environment),  the  low  skill  levels,  and  the  lack  of  good  tools. 
When  available,  tools  may  be  used  very  effectively,  e.  g.,  the  use  of  a  file 
manager  for  configuration  management  of  the  programs,  or  full  employment  of  the 
features  of  a  sophisticated  editor. 

In  general,  the  smaller  Government  MIS  organizations  do  not  lack  motivation  for 
tool  use  and  make  use  of  available  tools.  Frequently,  however,  they  lack  both 
the  knowledge  and  the  resources  to  use  tools  more  effectively.  They  will 
benefit  fromoutslde  assistance  In  all  of  the  areas  identified  In  3.2  above. 

As  far  as  tool  needs  are  concerned,  the  MIS  environment  presents  some  unique 
problems,  e.  g.,  the  lack  of  portability  of  most  COBOL  programs,  and  the 
run-time  Inefficiencies  caused  by  most  commercial  COBOL  compilers.  The  first 
problem  prevents  agencies  from  sharing  application  programs,  even  where  the 
purpose  served  and  the  records  to  be  generated  are  Identical,  unless  they  also 
have  the  same  computer.    The  lack  of  portability  Is  more  of  an  obvious  problem 
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In  this  environment  than  In  the  scientific  one  because  many  applications  are 
common  to  practically  every  business  environment:  payroll,  budgeting  physical 
asset  management,  and  billing.  Among  Government  agencies  there  are  further 
commonalities  due  to  Government  regulations.  Interaction  with  the  General 
Services  Administration,  and  requirements  of  the  Office  of  Management  and 
Budget.  In  addition  to  the  obstacles  which  the  lack  of  portabll  Ity  represents 
to  the  Interchange  of  programs.  It  also  creates  great  problems  If  a  computer  Is 
being  replaced  by  a  more  capable  model  from  a  different  manufacturer. 
Conversion  activity  due  to  replacement  of  a  central  computer  complex  can  extend 
over  several  years  and  represent  resource  expenditure  comparable  to  the  hardware 
cost. 

The  run  time  Inefficiencies  of  COBOL  compilers  could  be  tolerated  In  the  past 
(at  least  In  some  cases)  when  computer  programs  were  used  to  generate  periodic 
hard  copy  reports  which  would  then  serve  as  the  user's  primary  data  base.  The 
predominant  practice  today  Is  to  update  these  reports  continuously  and  to  make 
them  available  to  the  user  on  Interactive  terminals  rather  than  In  printed 
format.  This  puts  a  much  higher  premium  on  efficient  execution  of  programs 
because  of  the  more  frequent  access  and  the  need  for  a  rapid  response  to  user 
requests.  To  meet  the  demands  of  the  current  environment,  either  more  computers 
have  to  be  Installed  or  the  efficiency  of  the  object  code  has  to  be  Improved, 
The  latter  approach  has  some  obvious  limitations,  but  within  these  It  Is  a  much 
more  cost-effective  way  of  Improving  the  performance  of  a  computer  complex. 
Optimization  programs  of  several  types  are  available  to  deal  with  this  problem. 
These  are  not  commonly  In  use  In  smaller  organizations  of  any  type  but  they  are 
frequently  encountered  In  larger  MIS  organizations. 


3.4    THE  SMALLER  SCIENTIFIC  ENVIRONMENT 

The  typical  size  of  the  smaller  scientific  software  development  group  Is  also  25 
to  30  programmers,  and  two  levels  of  supervision  are  Involved-  The  lower 
supervisory  level  tends  to  be  application  oriented  but  the  top  supervisory 
function  operates  much  more  autonomously  than  In  equivalent  MIS  agencies. 
Though  constrained  by  budgets  that  are  determined  at  a  higher  managerial  level, 
the  second  level  scientific  supervisor  typically  assumes  full  responsibility  for 
the  technology  employed  within  his  or  her  organization.  Where  this  supervisor 
takes  an  Interest  In  software  technology,  structured  programming  supported  by 
appropriate  tools  Is  likely  to  be  used.  On  the  other  hand.  If  the  Interest  of 
the  supervisor  Is  confined  to  a  scientific  specialty  (simulations,  engineering 
analysis),  software  technology  can  be  a  very  low  priority  Item, 

Most  programmers  In  the  smaller  scientific  environment  have  an  engineering  or 
science  degree  but  their  formal  training  In  programming  may  not  be  very 
advanced.  Frequently,  It  consists  of  undergraduate  computer  or  programming 
courses,  supplemented  by  on-the-job  training  and  an  occasional  extension  course. 
In  some  groups  at  least  one  Individual  has  a  degree  In  computer  science  or  a 
related  field.  The  motivation  of  Individual  programmers  Is  governed  by  the 
needs  of  their  application.  In  the  simulation  field,  which  represents  a 
significant  part  of  the  smaller  scientific  programming  community,  the  code  tends 
to  be  bound  to  a  specific  facility.  Although  most  programming  Is  In  FORTRAN, 
there  may  be  frequent  recourse  to  assembly  routines  to  speed  up  the  execution. 
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As  a  rule,  structured  programming  Is  not  used  In  that  environment  although 
Individual  programmers  may  be  experimenting  with  It. 

Engineering  and  scientific  analysis  programs  are  sometimes  distributed  outside 
the  originating  organization,  and  In  those  cases  portability  Is  a  recognized 
requirement,  at  times  enforced  by  a  portability  analyzer.  Structured  and 
modular  programming  Is  used  more  frequently  than  In  the  simulation  field  but  Is 
seldom  formally  required.  Another  characteristic  of  the  engineering  or 
scientific  analysis  environment  that  affects  tool  usage  Is  that  many  programming 
tasks  are  of  less  than  3  months  duration,  and  much  of  that  time  Is  spent  on 
analysis  of  the  underlying  problem  rather  than  on  program  design  or 
Implementation.  This  discourages  the  use  of  tools  that  require  much  set-up  time 
or  a  lengthy  learning  period. 

The  emphasis  In  the  scientific  programming  environment  Is  more  on  the  generation 
of  new  programs  as  contrasted  with  maintenance.  Some  maintenance  activities, 
such  as  the  addition  of  a  major  feature  to  a  simulation,  or  the  extension  of  the 
capabilities  of  an  analysis  program,  are  regarded  as  creative  and  desirable 
assignments.  More  typical  maintenance  activities,  such  as  modifying  a  report 
format,  adapting  a  program  to  a  change  In  hardware  configuration,  or  correcting 
Interface  problems  are  regarded  as  less  desirable  assignments  and  are  given  to 
junior  personnel  as  "training". 

Supervisors  regard  the  documentation  and  detailed  maintenance  as  problem  areas. 
Although  these  are  recognized  as  essential  elements  of  the  organization's 
overall  assignment,  the  senior  programmers  take  little  Interest  In  them,  and  a 
good  methodology  Is  not  available  for  breaking  them  down  Into  tasks  that  could 
be  efficiently  handled  by  less  experienced  personnel  or  by  personnel  not 
Involved  In  the  direct  programming.  Some  smaller  organizations  make  effecrlve 
use  of  general  purpose  development  tools  to  strip  headers  and  comments  from 
programs  and  to  transform  these  Into  documentation.  More  typical  Is  the 
approach  where  supervisors.  In  some  cases  second  level  supervisors,  assume  the 
major  responsibility  for  the  review  of  documentation. 

A  very  significant  part  of  the  overall  activity  In  the  simulation  field  Is 
version  control.  New  assignments  frequently  consist  of  assembling  existing 
modules,  some  with  minor  changes.  Into  a  new  configuration.  File  management 
systems  can  be  used  very  effectively  to  assist  In  this  process.  Editors  and 
preprocessors  (usually  without  extensive  analysis  features)  are  other  typical 
tools  currently  used  In  this  environment. 

By  and  large  the  scientific  programming  organizations  have  the  technical  ability 
to  acquire  and  Install  software  tools.  They  may  lack  specific  Information  on 
tools  suitable  for  their  environment,  the  resources  for  the  Introduction,  and 
frequently  also  the  motivation  to  devote  part  of  their  effort  to  software 
engineering.  Because  of  the  recognized  difficulties  In  documentation  and 
maintenance,  the  second  level  supervisors  will  be  particularly  receptive  to 
tools  that  can  simplify  the  work  In  these  areas. 
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SECTION  4 
USER  TOOL  NEEDS 


This  section  discusses  those  aspects  of  user  tool  needs  that  are  pertinent  to 
the  development  of  guidance  for  the  Introduction  of  tools.  Subsection  4.1 
considers  organizational  factors  of  tool  needs  that  are  largely  Independent  of 
the  application  area.  This  Is  followed  In  subsection  4.2  by  a  detailed 
Identification  of  tool  features  desired  In  the  target  environments  described  In 
Section  3.  Even  experienced  tool  users  can  be  faced  with  severe  problems  In  the 
adoption  of  new  tools,  and  the  needs  that  arise  In  this  connection  are  addressed 
In  subsection  4.3.  The  final  part  of  this  section  describes  resources  available 
to  the  potential  tool  user  for  selection  of  specific  tools  to  meet  the  needs 
characterized  in  the  earlier  parts. 

4.1    ORGANIZATIONAL  FACTORS  IN  TOOL  NEEDS 

The  objectives  of  tool  usage  (and  hence  the  objectives  of  many  tool  features) 
are  determined  largely  by  the  user's  organizational  environment  and  by  the 
management  level  that  authorizes  tool  acquisitions.  Because  these 
considerations  hold  for  all  application  areas,  they  are  discussed  at  the 
beginning  of  this  section.  For  a  tool  to  be  readily  accepted,  it  must  help  in 
areas  of  concern  to  the  management  that  authorizes  the  acquisition  and 
Introduction  activities.  Thus,  If  management  considers  program  documentation  to 
be  a  particularly  critical  area  It  may  be  difficult  to  obtain  authorization  for 
the  Introduction  of  test  tools.  The  organizational  entities  that  may  be 
involved  In  the  acquisition  and  use  of  software  tools  are  described  under  the 
headings  of: 

Software  Development  Organization, 
Project  Management,  and 
Functional  Management. 


4.1.1    Software  Development  Organization 

The  term  development  Is  used  In  a  broad  sense  that  Includes  all  the  activities 
directly  involved  in  generating  and  maintaining  programs-  Practically  all 
software  development  organizations  desire  tools  that: 

Increase  productivity. 

Reduce  skill  requirements. 

Automate  routine  aspects  of  software  design. 

Help  In  software  maintenance. 

To  some  extent  the  last  three  Items  are  individual  facets  of  the  first.  At  the 
present  time  there  are  few  tools  that  are  specifically  aimed  at  a  reduction  of 
skill  requirements.    The  creative  and  cognitive  skills  required  for  designing  a 
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sound  software  structure  are  not  easily  packaged  Into  a  software  tool.  However, 
the  automation  of  routine  tasks  Is  a  very  widely  addressed  tool  objective. 
Because  they  relieve  creative  personnel  from  tedious  aspects  of  design,  coding, 
and  testing,  these  tools  compensate  partly  for  the  lack  of  those  that  reduce  the 
skill  levels.  They  also  contribute  to  Increased  productivity.  Examples  of  such 
tools  are  editors  and  precompilers  used  for  the  preparation  or  conversion  of 
source  files,  formatters  for  the  preparation  of  reports,  and  sort/merge 
programs.  The  most  common  tool  features  that  automate  routine  tasks  are 
editing,  formatting,  comparison,  translating,  and  scanning.  Tools  that  help  In 
software  maintenance  Include  most  of  those  cited  for  the  automation  of  routine 
tasks  plus  file  managers  or  library  systems.  In  addition,  maintenance  may  make 
use  of  special  functions  In  editing  or  scanning  tools,  e.  g.,  to  locate 
variables  or  to  strip  code  from  a  source  file.  The  latter  feature  Is  useful  for 
creating  documentation  from  the  program  comments. 

AM  of  the  tool  functions  and  features  enumerated  here  are  of  direct  benefit  to 
the  software  professional,  and  there  Is  seldom  any  difficulty  In  Introducing 
them  at  the  working  level  If  they  provide  a  reasonably  friendly  user  Interface. 
Line  management  In  the  software  development  organization  may  need  to  be 
convinced  that  the  cost  of  the  tool  acquisition  and  Introduction  will  be 
recovered  over  a  reasonably  short  time  span.  Note  that  the  use  of  these  tools 
Is  largely  Independent  of  emphasis  on  standards  that  may  prevail  In  the  using 
organization. 

Where  standards  are  In  use,  additional  tools  will  be  desired  that  either 
facilitate  or  enforce  compliance.  Among  the  former  are  program  design  language 
processors,  and  among  the  latter  are  code  auditors.  Environments  that  emphasize 
standards  usually  also  demand  discipline  in  the  procedural  aspects  of  software 
development  such  as  version  control,  access  to  test  cases,  etc.  File  managers 
and  library  systems  will  be  found  helpful  In  enforcing  this  discipline.  Tools 
that  support  standards  will  be  readily  accepted  by  a  standards-minded  line 
management.  The  professionals  who  have  to  use  the  tools  may  regard  them  with 
Indifference  or  even  hostility.  Part  of  this  Is  due  to  apprehension  about 
having  one*s  work  scrutinized  by  "Big  Brother",  and  part  Is  due  to  obstacles  to 
Innovation  (deviation  from  standards)  which  these  tools  may  present.  It  Is 
therefore  Important  that  tools  of  this  type  have  a  particularly  good  user 
Interface  so  that  potential  complaints  about  their  use  can  be  minimized-  Some 
tools,  such  as  auditors,  can  be  combined  with  the  compiler  so  that  they  are 
automatically  Invoked  when  a  new  source  file  Is  submitted.  This  Integration 
makes  more  efficient  use  of  the  computer  and  at  the  same  time  avoids  problems  at 
the  user  Interface. 

That  they  support  or  enforce  standards  Is  a  particularly  pertinent  factor  In 
connection  with  the  Introduction  of  software  tools  to  Government  agencies. 
Beyond  the  benefits  that  always  attend  uniformity  of  design  practices. 
Government  agencies  will  find  It  easier  to  Interchange  both  programs  and 
personnel  If  common  standards  can  be  adopted.  Some  of  these  benefits  transcend 
the  usual  concerns  of  the  software  development  organization.  The  broader 
aspects  of  tool  usage  to  support  software  standards  are  discussed  under 
Functional  Management  In  4.1.3. 
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Because  Government  agencies  can  have  access  to  tools  developed  or  In  use  by 
other  Government  organizations,  they  may  particularly  benefit  from  the 
appointment  of  a  local  too  I  smith  —  a  person  expert  In  tool  usage  who  may  be 
able  to  make  software  or  minor  hardware  modifications  that  permit  a  tool  to  be 
used  In  a  new  environment.  The  role  of  the  tool  smith  was  Introduced  several 
years  ago  as  a  specialist  within  a  software  development  team  In  these  words 
CBROOTSJ: 

(The  team  leader)  needs  a  too  I  smith,  responsible  for  ensuring  this  adequacy 
of  the  basic  service  and  for  constructing,  maintaining,  and  upgrading 
special  tools  —  mostly  Interactive  computer  services  —  needea  by  his 
team.  Each  team  will  need  Its  own  toolsmlth,  regardless  of  the  excellence 
and  reliability  of  any  centrally  provided  service,  for  his  Job  Is  to  see  to 
the  tools  needed  or  wanted  by  his  (team),  without  regard  to  any  other 
team's  needs.  The  tool-bullder  will  often  construct  specialized  utilities, 
catalogued  procedures,  and  macro  libraries. 

The  designation  of  a  dedicated  toolsmlth  within  each  team  may  be  a  higher  degree 
of  specialization  than  can  be  warranted  In  smaller  software  organizations. 
However,  within  each  software  environment  that  makes  use  of  a  single  computing 
facility  such  a  specialist  will  be  found  very  effective  and  certainly  very 
valuable  for  the  Introduction  of  new  tools. 


4.1.2    Project  Management 

Project  management  directs  the  software  development  on  behalf  of  the  ultimate 
user.  It  Is  usual ly  more  Interested  In  the  functional  and  Interface  aspects  of 
the  programs  than  In  structural  or  standards  aspects.  Where  project  management 
Is  funding  the  acquisition  of  software  tools,  there  may  be  heavy  emphasis  on 
tools  that  have  an  Immediate  payoff  In  terms  of  project  objectives-  Some  of 
these  tools  may  be  software  development  tools  but  the  nature  of  these  Is  project 
dependent  and  can  not  be  predicted. 

There  are,  however,  some  software  tools  that  make  a  direct  contribution  to 
project  management,  and  this  area  of  tools  usage  Is  expected  to  be  expanded  In 
the  near  future.  Some  programs  of  this  kind  are  general  purpose  scheduling  and 
reporting  algorithms  that  share  more  of  the  characteristics  of  application 
programs  than  those  of  software  tools.  Others,  however,  are  very  specific  to 
the  software  area  and  extract  Information  from  the  software  as  It  Is  being 
developed.  These  are  appropriately  described  as  software  tools  for  project 
management  and  are  further  described  below. 

Software  library  systems  have  already  been  mentioned  In  the  previous  heading  as 
tools  that  can  support  disciplined  development  and  aid  In  software  maintenance. 
For  project  management  they  can  furnish  the  Identification  and  date  of  the 
latest  revision,  current  file  size  (number  of  statements),  and  change  In  size 
over  a  selected  time  Interval,  Either  by  themselves  or  In  conjunction  with  the 
operating  system  log,  these  tools  can  also  furnish  reports  on  the  total  number 
of  runs,  the  number  of  statement  changes,  the  number  of  different  test  cases 
submitted,  and  the  number  of  compilation  failures  or  aborted  runs.  All  of  this 
information  can  be  furnished  In  hard  copy  or  Interactively  on  a  terminal.  In 
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either  format,  tools  furnish  these  data  more  conveniently  and  at  a  fraction  of 
the  cost  of  manual  methods. 

Tools  for  cost  estimation  are  also  Important  for  the  project  management  area. 
Development  cost,  life  cycle  cost,  and  computer  cost  aspects  can  be  estimated  by 
means  of  software  tools.  Development  costs  are  estimated  by  automating  an 
estimation  algorithm  such  as  CD0TY77],  Life  cycle  costs  can  be  developed  as  an 
extension  of  the  development  costs,  such  as  In  the  ESD  model  CJAME77X  or  from 
data  on  a  system  under  development  such  as  |lPUTN78l].  Computer  cost  aspects  are 
estimated  by  sizing  and  timing  tools.  While  the  jury  Is  still  out  on  the 
accuracy  of  the  cost  estimates  generated  by  these  tools  at  present,  there  Is 
little  doubt  that  their  use  promotes  systematic  collection  of  software  cost  data 
and  a  methodical  approach  to  software  costing. 

Since  the  emphasis  In  this  report  Is  on  the  Introduction  of  tools  to  smaller 
programming  environments.  It  should  be  noted  that  not  all  project  management 
tools  need  to  be  very  large  systems.  Management  will  frequently  derive 
considerable  benefits  from  small  programs  that  automate  follow-up  on  action 
Items,  receipt  of  deliverables  from  vendors,  etc.  Programs  of  this  type  can  be 
applied  In  any  environment  regardless  of  size. 


4,1.3    Functional  Management 

In  organizations  where  software  Is  being  developed  for  more  than  one  project, 
the  Individual  development  groups  usually  report  to  a  common  management  level 
which  Is  referred  to  here  as  the  functional  management  or  computing  function 
management.  Because  personnel  must  be  periodically  reassigned  to  new  projects, 
functional  management  will  usually  be  Interested  In  uniformity  of  practices 
among  projects  so  that  retraining  can  be  minimized.  Computing  function 
management  can  thus  be  expected  to  be  standards-oriented  and  to  support  the 
Introduction  of  tools  that  enforce  standards.  This  management  level  Is  usually 
Inclined  to  take  a  long  range  view  and  may  favor  the  acquisition  of  tools  that 
primarily  benefit  later  software  llfecycle  phases,  e.  g.,  requirements  analyzers 
(although  these  are  used  during  the  definition  stage,  the  major  benefits  are 
usually  reduced  maintenance  costs  during  the  operation  phase). 

Functional  management  Is  usually  also  Involved  In  another  Important  aspect  of 
the  Introduction  of  software  tools:  It  must  furnish  or  allocate  the  facilities 
for  the  execution  of  the  tools.  Very  few  computing  facilities  have  excess 
capacity,  and  this  Is  particularly  true  for  Government  computing  facilities. 
Therefore,  the  management  of  the  computing  function  may  object  to  the 
Introduction  of  tools  that  extend  the  execution  time  or  that  add  Job  steps  to 
frequently  run  programs.  Where  a  tool  has  a  significant  adverse  impact  on 
throughput,  the  benefits  of  that  tool  In  areas  of  concern  to  functional 
management  should  be  highlighted:  Increased  programmer  productivity,  adherence 
to  standards,  or  Improved  software  quality. 
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Because  tool    Integration  avoids  repeated  reformatting  and  multiple  data 
retrievals.  It  reduces  computer  usage  and  supports  the  goals  of  functional 
management.    It  Is  at  this  management  level  that  the  greatest  recognition  of  the 
benefits  of  tool  Integration  efforts  can  be  expected. 

Functional  management  will  also  be  Interested  In  tools  useful  for  the  management 
of  the  computing  facility,  e.  g.,  those  that  allocate  charges  to  users,  that 
report  on  the  operation  of  the  current  facilities,  and  simulation  tools  that  aid 
In  planning  of  Improvements.  The  features  of  Instrumentation,  resource 
utilization,  simulation,  and  statistical  analysis  support  the  capab  1 1 1  ties  of 
such  tools. 


4.2    APPLICATION  FACTORS  IN  TOOL  NEEDS 

The  following  discussion  focuses  on  the  needs  of  the  two  environments  that  were 
Identified  In  Section  3  as  the  primary  targets  for  the  Introduction  of  software 
tools:  the  smaller  MIS  organization  and  the  smaller  scientific  programming 
organization.  In  the  studies  leading  to  the  definition  of  tool  needs,  six 
application  areas  were  considered:  business-oriented  batch  systems-  management 
Information  systems,  office  automation  systems,  on  I  I ne  transaction  driven 
systems,  real  time  command  and  control  systems,  and  scientific  or  engineering 
programs.  It  was  found  that  the  tool  needs  of  the  first  four  of  these  were  very 
similar,  and  this  entire  group  Is  encompassed  by  the  discussion  In  4.2.1  below. 
Also,  the  software  tool  needs  of  the  last  two  categories  were  Identical,  and 
these  are  described  In  4.2.2  below.  Within  this  subsection  It  Is  assumed  that 
the  tool  types  and  features  required  for  the  general  software  development 
organization  C4.1.1  above]  are  provided,  and  therefore  only  the  supplements 
dictated  by  the  specific  application  areas  are  discussed. 


4.2.1    Tool  Needs  of  Smaller  MIS  Organizations 

One  of  the  distinctive  tool  needs  of  this  environment  arises  from  the  use  of 
COBOL  and  the  Inefficiencies  of  COBOL  compilers  that  were  mentioned  earlier 
C3.3I1.  A  sizeable  number  of  commercial  tools  have  been  developed  to  Improve  the 
performance  of  COBOL  programs.  Two  specific  techniques  have  been  found 
particularly  helpful  In  this  area:  modifying  the  object  code  for  Improved 
performance  (the  significant  tool  feature  for  this  Is  optimization),  and 
determining  and  simplifying  the  parts  of  the  program  which  account  for  the  bulk 
of  the  run  time  (the  significant  tool  feature  for  this  Is  tuning).  Of  course 
both  of  these  can  also  be  used  together.  Tuning  Is  part  of  the  dynamic  analysis 
function.  It  generally  requires  Instrumenting  the  program,  I.  e.,  the  Insertion 
of  code  that  counts  the  number  of  accesses  to  the  program  segments  of  Interest. 
Once  this  Is  done,  other  attributes  of  the  program's  structure  and  performance 
can  also  be  evaluated,  and  such  options  are  provided  In  several  of  the 
optimization  tools.  In  connection  with  the  Introduction  of  tools  Into  the 
smaller  MIS  organization.  It  Is  suggested  to  avoid  such  additional  capabilities 
In  the  tool  Initially  because  they  extend  the  run-time  of  the  Instrumented 
program,  and  they  make  the  user  Interface  more  complex  than  It  needs  to  be. 
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Tools  can  be  used  very  effectively  to  aid  In  program  conversion  (e.  g..  when  a 
new  computer  Is  being  Installed)  which  can  present  many  probleffis  In  the  smal  I  er 
MIS  environment.  Over  270  conversion  tools  are  listed  In  a  publication  of  the 
Federal  Conversion  Support  Center  [FCSCSOH.  The  listing  Includes  tools  that 
facilitate  conversion  (e,  g.,  translators),  as  well  as  programs  that  may 
eliminate  the  need  for  conversion  (e.  g,,  emulators). 

Because  of  the  heavy  Involvement  of  the  MIS  applications  area  In  the 
manipulation  of  data  structures,  tools  that  simplify  data  base  updating  and 
restructuring  are  another  specific  need  of  this  environment.  While  program 
libraries  and  general  purpose  file  management  systems  mentioned  In  4.1.1  can  be 
of  some  help  for  updating,  specialized  systems  for  data  base  management  are 
preferred,  A  number  of  these  are  commercially  available,  and  they  frequently 
combine  access  control,  archiving  (or  providing  an  audit  trail),  auditing  for 
completeness  and  reasonableness  of  the  Inserted  data,  and  restructuring  with  the 
update  capability.  Data  encryption  Is  offered  as  an  optional  feature  of  some 
tools  but  Is  not  considered  essential  for  the  smaller  MIS  environment. 


4.2,2    Tool  Needs  of  the  Smaller  Scientific  Programming  Environment 

Just  as  the  use  of  COBOL  Is  responsible  for  some  specific  tool  needs  In  the  MIS 
environment,  the  use  of  FORTRAN,  the  current  leading  language  in  the  scientific 
programming  environment,  has  in  the  past  also  been  a  strong  motivator  for 
specific  tools.  In  this  case  pre-processor s  for  structured  languages. 
Pre-processors  frequently  represent  the  most  advanced  software  tool  in  the 
inventory  of  smaller  scientific  programming  organizations.  Even  though 
pre-processors  will  continue  to  be  used,  it  Is  suggested  that  a  forward  looking 
program  for  the  Introduction  of  tools  to  the  smaller  scientific  programming 
environment  not  emphasize  this  tool  type  unduly.  One  of  the  reasons  Is  that.  In 
scientific  programming  for  the  defense-connected  sector,  FORTRAN  Is  being 
replaced  by  languages  which  inherently  support  structured  programming  practices, 
and  another  reason  is  that  suitable  control  constructs  are  evolving  for  FORTRAN 
Cans  178].  But  more  fundamental  Is  the  need  to  educate  the  scientific  programmer 
In  the  smaller  organization  to  the  benefits  of  a  methodical  approach  to  program 
development  of  which  structured  programming  is  but  a  part. 

This  need  can  be  met  by  a  general  purpose  development  tool  package  that  takes 
the  drudgery  out  of  some  of  the  routine  programming  steps.  One  such  package, 
described  In  the  professional  literature  liKERN76ll.  Is  In  the  public  domain. 
This  approach,  which  Is  cited  only  as  an  example.  Involves  a  number  of 
Independent  utilities  that  can  be  Invoked  Individually  or  interactively  by  means 
of  a  command  line  processor  to  do  editing,  file  management,  formatting,  and 
pre-processing.  The  efficient  application  of  the  tools  poses  an  Intellectual 
challenge  that  may  be  particularly  motivating  for  scientific  and  engineering 
personnel  who  are  the  programmers  In  this  environment.  Software  tool  packages 
patterned  along  these  lines  are  In  use  In  some  smaller  scientific  environments, 
and  the  user  reaction  seems  to  be  favorable. 
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Once  a  scientific  programming  organization  Is  committed  to  a  disciplined 
development  approach  (and  as  previously  explained  some  of  the  smaller 
organizations  are  already  at  that  point),  needs  for  many  static  analysis 
features  may  arise.  Including  code  auditing,  completeness  checking,  consistency 
checking,  error  checking,  and  statistical  analysis.  Tools  with  these 
capabilities  will  be  particularly  desired  for  design  analysis  programs 
supporting  critical  applications  (nuclear  Industry,  aircraft  structures)  and  for 
simulations  which  furnish  output  to  physically  active  equipment  (e.  g.,  moving 
base  flight  simulators).  At  present,  smaller  organizations  may  find  It 
difficult  or  Impossible  to  acquire  these  tools  In  a  useful  format.  Once  a 
general  purpose  development  tools  package  is  In  use,  the  additional  checking 
tools  can  be  developed  In-house.  Commercial  sources  may  become  Interested  in 
adding  checking  functions  to  an  established  basic  tools  package. 

Real-time  command  and  control  systems  pose  additional  requirements  that  may 
require  dynamic  analysis  features.  At  present,  this  applications  area  Is 
primarily  served  by  large  organizations  that  make  extensive  use  of  tools,  the 

4.2.3    Summary  of  Tool  Features  Determined  by  the  Application 

Table  4-1  lists  common  and  application-dependent  tool  features.  The  first 
column  lists  features  desired  by  all  software  development  organizations  as 
described  In  4,1.1.  The  features  shown  In  the  table  are  the  ones  most  desired 
by  new  tool  users.  The  selection  Involved  some  Judgment  regarding  the 
priorities  that  exist  within  the  software  development  organization  and  Its  user 
community.  Thus,  that  error  checking  is  found  in  the  scientific  column  but  not 
In  the  MIS  column  does  not  Imply  that  this  feature  is  not  suitable  or  not 
Important  In  the  MIS  environment.  It  does  mean  that  most  smaller  MIS  developers 
will  place  a  lower  priority  on  error  checking  than  on  the  features  listed  In  the 
MIS  column. 


TABLE  4  -  1    FEATURES  DETERMINED  BY  THE  APPLICATION 


Features  Needed  For 


Common 


MIS  Programming 


Scientific  Programming 


Editing 
Scanning 


Optimization 
Tuning 

Restructur i  ng 
Auditing  (Data) 


Auditing  (Code) 


FormattI ng 
Comparl son 
Trans  I  at I  on 
Management 


Completeness  Checking 
Statistical  Analysis 
Error  Checking 


Consistency  Checking 
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4.3    NEEDS  OF  OTHER  ENVIRONMENTS 


Although  large  and  very  large  software  organizations  are  In  most  cases  already 
users  of  general  purpose  software  tools,  they  may  benefit  from  programs  aimed 
at  Improving  access  to  tools,  standardization  of  tool  Interfaces,  or 
establishing  minimum  requirements  for  tool  documentation  and  diagnostics. 
Because  these  organizations  (which  will  be  collectively  called  "larger")  have 
multiple  general  purpose  tools  In  Inventory,  the  Integration  of  tools  Is 
particularly  pertinent  for  them.  There  are  at  present  no  clear  Indications  of 
the  direction  that  tool  Integration  should  take.  However,  there  Is  a 
considerable  effort  being  devoted  to  the  area  of  progranmlng  environments  within 
NBS  and  elsewhere,  and  tool  Integration  Is  an  Important  aspect  of  these 
activities  [BRAN81,  IEEE81]. 

The  Integration  of  tools  provides  two  primary  benefits:  a  simplified  user 
Interface  and  reduced  utilization  of  computer  resources.  The  simplified  user 
Interface  Is  achieved  by  requiring  less  file  manipulation  for  converting  the 
output  of  one  tool  Into  an  Input  for  another,  by  consistent  tool  calling 
conventions.  Input  commands,  and  output  formats,  and  by  the  capability  for 
Invoking  processing  by  several  tools  with  a  single  command  string  These 
benefits  will  In  turn  simplify  documentation  and  training  and  In  general  Improve 
the  user  acceptance  of  a  system  of  multiple  tools. 

The  reduced  utilization  of  computer  resources  Is  partly  due  to  the  factors  just 
enumerated,  particularly  the  avoidance  of  file  manipulations,  and  partly  due  to 
the  possibility  of  combining  computer- 1 n tens  I ve  operations  such  as  parsing  and 
searching  which  are  now  carried  out  separately.  As  mentioned  In  4.1.3,  the 
managers  of  the  computing  function  will  particularly  appreciate  these  latter 
benefits.  The  reduction  In  running  time  and  storage  requirements  together  with 
the  benefits  due  to  the  simplified  user  Interface  promise  a  high  payoff  for 
efforts  In  the  tool  integration  area, 

A  significant  step  for  the  Integration  of  tools  developed  by  different  sources 
Is  represented  by  the  NBS/ICST  study  of  compiler-based  tools  CBRAY81J.  The 
association  of  the  tool  with  the  compiler  provides  access  to  at  least  two 
(source  and  object)  and  sometimes  three  (parsed  code)  representations  of  the 
program,  and  also  makes  the  data  and  structure  checking  features  of  the  compiler 
available  to  the  tool.  A  possible  disadvantage  of  this  approach  Is  that  a 
compiler  pass  may  be  required  In  order  to  Invoke  a  tool.  The  adherence  to  a 
single  (or  at  least  compatible)  file  format  for  multiple  tools  can  be  readily 
enforced  by  compiler  basing. 

The  Integration  of  tools  Is  very  significant  for  extending  tool  usage  In 
environments  where  general  purpose  tools  are  already  in  use.  It  Is  of  lesser 
Importance  for  the  Introduction  of  tools  to  environments  that  had  no  prior 
experience  with  general  purpose  software  tools,  and  It  is  therefore  addressed 
here  In  only  a  limited  way. 

A  topic  partly  contained  within  the  area  of  tool  Integration  Is  the 
standardization  of  tool   commands  and  output  formats.     The    lack  of 
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standardization  Is  particularly  obvious  and  disadvantageous  In  editors  and 
related  tools  (Including  word  processors).  These  are  among  the  most  widely  used 
tools,  they  are  frequently  the  medium  through  which  the  Input  to  other  tools  Is 
processed,  and  there  Is  better  agreement  than  In  most  other  areas  on  the 
functions  which  the  tool  Is  required  to  furnish.  There  Is  thus  ample  motivation 
to  standardize  but  very  few  concrete  accomplishments. 

There  are  at  present  many  different  methods  for  cursor  positioning,  different 
commands  for  deleting  characters,  words,  or  lines,  and  different  procedures  as 
well  as  commands  for  string  search  or  substitution.  These  inconsistencies  cause 
errors,  necessitate  multiple  training  periods,  and  certainly  constitute  a 
deterrent  to  tool  usage.  In  view  of  the  basic  need  for  an  editor  In  the  use  of 
many  tools,  the  lack  of  standardization  of  editor  commands  must  be  regarded  as 
an  obstacle  to  the  introduction  of  tools. 


4.4    RESOURCES  FOR  TOOL  SELECTION 

In  subsections  4.1  and  4.2  a  number  of  generic  tool  types  and  features  have  been 
Identified  as  suitable  for  the  Introduction  of  tools  to  specified  organization 
and  application  environments.  The  present  subsection  discusses  the  additional 
steps  necessary  for  the  actual  selection  of  a  tool. 

Catalogues  of  software  tools  are  available  from  the  commercial  tool  developers, 
computer  manufacturers^  and  computer  users*  groups.  For  obvious  reasons,  the 
offerings  in  each  of  these  are  restricted  although  the  restriction  imposed  by 
the  last  of  these  may  be  an  appropriate  one  if  only  the  computer  type  addressed 
by  that  users'  group  is  available  as  a  tool  host  and  if  the  group  has  conducted 
a  comprehensive  survey  of  suitable  tools. 

A  recent  publication  by  the  National  Bureau  of  Standards  Is  particularly  helpful 
for  the  Introduction  of  tools  to  smaller  programming  environments  IIH0UG82],  It 
contains  cross  references  by  tool  classification  (function)  and  features  which 
makes  it  especially  suitable  for  use  with  the  tool  Identifications  used  in  this 
report. 

Once  a  tool  that  meets  the  functional  requirements  Is  identified,  the  main 
section  of  the  catalogue  must  be  consulted  to  see  whether  the  tool  Is  usable  on 
an  aval  I  ab  I  e  computer,  whether  It  handles  an  appropriate  source  language  (or 
other  Input  format),  and  whether  It  can  be  obtained  in  a  suitable  Implementation 
language.  Other  considerations  are  the  licensing  arrangements,  availability  of 
documentation  and  training,  and  the  computer  resource  utilization. 

Some  difficulties  are  usually  encountered  that  must  be  resolved  by  language 
conversions  (of  either  Input  or  the  tool)  or  other  tool  modifications. 
Consultation  with  a  toolsmith  will  be  valuable  in  this  connection.  Government 
agencies  will  want  to  know  whether  other  agencies  are  currently  using  the  tool, 
and  a  central  tool  usage  catalogue  will  be  a  beneficial  facility.  Access  at  a 
remote  computer  can  be  a  very  effective  first  step  In  a  detailed  evaluation  of 
the  tool.  Hosting  problems  may  be  overcome  by  remote  access  even  on  a  longer 
term  basis. 
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SECTION  5 
DEVELOPMENT  OF  EVEMT  SEQUENCES 

While  the  preceding  sections  have  discussed  the  tool  needs  In  selected 
environments,  this  section  describes  the  detailed  events  that  will  lead  to 
successful  use  of  tools.  The  first  subsection  describes  the  purpose  and 
rationale  for  an  event  sequence,  and  the  second  subsection  recommends  a  specific 
event  sequence  for  the  smaller  MIS  and  scientific  environments. 


5.1    PURPOSE  OF  EVENT  SEQUENCES 

The  management  of  any  significant  project  requires  that  the  work  be  divided  Into 
tasks  for  which  completion  criteria  can  be  defined.  The  transition  from  one 
task  to  another  Is  called  an  event,  and  to  permit  orderly  progress  of  the 
activities,  here  the  Introduction  of  a  software  tool,  the  scheduling  of  these 
events  must  be  determined  In  advance.  A  general  outline  for  such  a  schedule  Is 
provided  by  the  event  sequence  described  In  the  next  subsection.  The  actual 
calendar  time  schedule  will  depend  on  many  factors  which  must  be  determined  for 
each  specific  tool  use  (particularly  on  the  time  required  for  procurement  of  the 
tool  and  training).  One  of  the  formats  used  for  the  event  sequence  Is 
consistent  with  the  Critical  Path  Method  (CPM)  of  project  scheduling  and  can  be 
used  with  that  technique  for  the  development  of  an  optimum  calendar  time 
schedu I e. 

Most  of  the  activities  Included  In  the  event  sequence  are  obviously  necessary 
but  a  few  were  Included  specifically  to  avoid  difficulties  encountered  In 
previous  tool  procurements.  Quite  frequently  tools  were  obtained  'through  the 
side  door'  without  adequate  consideration  of  the  resources  required  for  the 
effective  employment  of  the  tool  and  without  determination  by  a  responsible 
manager  that  the  tool  served  a  primary  need  of  the  organization.  Tools  acquired 
In  this  manner  were  seldom  used  in  an  optimal  way  and  were  sometimes  discarded. 
Experiences  of  this  type  are  not  conducive  to  gaining  widespread  acceptance  of 
tools  In  the  smaller  programming  environments  where  the  activities  required  for 
the  Introduction  of  tools  will,  under  the  best  of  circumstances.  Impose  a  severe 
drain  on  resources.  A  key  feature  of  the  proposed  approach  Is,  therefore,  that 
tool  usage  will  be  Initiated  only  In  response  to  an  expressed  management  goal 
for  software  development  or  for  the  entire  computing  function. 

Difficulties  In  the  Introduction  of  tools  can  arise  In  three  areas: 

Organizational  obstacles 
Problems  arising  from  the  tools 
Obstacles  In  the  computer  environment 

The  Individual  activities  described  below  as  well  as  the  ordering  of  the  event 
sequence  are  designed  to  eliminate  as  many  of  these  difficulties  as  possible. 
They  are  most  effective  with  regard  to  the  first  category  and  probably  least 
effective  with  regard  to  the  last  category.  The  need  for  Involving  a  reponslble 
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management  level  In  the  tool  Introduction  has  already  been  mentioned,  and  this 
Is  Indeed  the  key  provision  for  avoiding  organizational  obstacles.  "Responsible 
management"  Is  that  level  that  has  the  authority  to  obligate  the  resources 
required  for  the  Introduction  process.  The  scope  of  the  resource  requirement 
will  become  clearer  after  all  Introduction  activities  have  been  described. 
Because  the  criterion  for  the  selection  of  the  management  focus  Is  Its  ability 
to  commit  funds,  this  management  level  Is  hereafter  referred  to  as  funding 
management.  In  some  organizations  this  may  be  the  project  management  as  defined 
In  4,1.2,  in  some  It  may  be  functional  management  as  defined  in  4.1.3,  and  In 
yet  others  It  may  be  an  agency  or  department  management  not  specif  leal  ly 
Identified  with  a  computing  function.  It  should  be  involved  in  at  least  the 
following  activities  associated  with  the  Introduction  of  tools: 

1.  Identifying  the  goals  to  be  met  by  the  tool  (or  by  the  technique  supported 
by  the  tool),  and  assigning  responsibility  for  the  activities  required  to 
meet  these  goals. 

2.  Approving  a  detailed  tool  acquisition  plan  that  defines  the  resource 
requirements  for  procurement  and  In-house  activities. 

3.  Approving  the  procurement  of  tools  and  training  If  this  Is  not  explicit  In 
the  approval  of  the  acquisition  plan, 

4.  Determining  after  some  period  of  tool  use  whether  the  goals  have  been  met. 

Additional  organizational  obstacles  must  be  overcome  by  actions  of  the  software 
management  (local  management  of  the  organization  that  will  Introduce  the  tool), 
A  pitfall  that  must  be  avoided  is  assigning  the  details  of  the  tool  acquisition 
as  a  sideline  to  an  Individual  who  carries  many  other  responsbl I ities.  Even  In 
a  smal  I  software  organization  (up  to  14  programmers).  It  should  be  possible  to 
make  the  tool  Introduction  the  principal  assignment  of  an  experienced  individual 
with  adequate  professional  background.  This  person  Is  referred  to  as  the 
software  engineer.  In  medium  size  organizations  (15  to  39  programmers)  several 
Individuals  may  be  Involved  In  software  engineering  tasks  (not  restricted  to 
tool  usage),  and  this  may  constitute  a  software  engineering  function. 

Further,  the  event  sequence  Includes  activities  of  a  toolsmith  who  will  not  be 
the  same  person  as  the  software  engineer  In  most  cases-  The  former  assignment 
requires  expertise  In  systems  programming  and  specialized  knowledge  of  the  tool 
to  be  Introduced.  The  duties  of  the  software  engineer  Involve  planning  project 
management,  and  obtaining  cooperation  from  a  variety  of  Individuals  and 
organizations.  Where  there  Is  a  software  engineering  function,  the  toolsmith  Is 
typical  ly  a  member  of  It, 

Obstacles  arising  from  the  tools  themselves  are  expected  to  be  avoided  In  the 
event  sequence  by  a  careful,  methodical  selection  of  tools.  In  particular, 
distinct  contributions  to  the  tool  selection  are  specified  for  software 
management  and  the  software  engineer.  Software  management  Is  assigned 
responslbi I  tty  for: 
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Identifying  tool  objectives. 

Approving  the  acquisition  plan  (It  may  also  require 
approval  by  funding  management). 

Defining  selection  criteria. 

Making  the  final  selection  of  the  tool  or  the  source. 
The  software  engineer  Is  responsible  for: 
Identifying  candidate  tools. 

Applying  the  selection  criteria  (In  Informal  procurement) 
or  preparing  RFP  Inputs  (In  formal  procurement). 

Preparing  a  ranked  list  of  tools  or  sources- 

Further,  the  ultimate  user  of  the  tool   Is  Involved  In  the  recommended  event 
sequence  In  reviewing  either  the  list  of  candidate  tools  or,   for  formal 
procurement,  the  tool  requirements. 


This  distribution  of  responsibilities  reduces  the  chances  of  selecting  a  tool 
that  (1)  does  not  meet  the  recognized  needs  of  the  organization,  (2)  Is 
difficult  to  use.  (3)  requires  excessive  computer  resources,  or  (4)  lacks 
adequate  documentation.  The  repeated  exchange  of  Information  required  by  the 
process  outlined  above  will  also  avoid  undue  emphasis  on  very  short-term 
objectives  which  may  lead  to  selection  of  a  tool  on  the  basis  of  availability 
rather  than  suitability. 

The  obstacles  to  tool  usage  that  reside  In  the  computer  environment  are 
primarily  due  to  the  great  diversity  of  computer  architectures  and  operating 
system  procedures,  and  to  the  lack  of  portability  In  most  software  tools. 
Activities  associated  with  the  Introduction  of  tools  can  only  modestly  alleviate 
these  difficulties.  The  event  sequence  provides  the  following  help  In  this 
area: 

1.  A  methodical  process  of  Identifying  candidate  tools  and  selecting  among 
these  on  the  basis  of  established  criteria.  This  will  avoid  some  of  the 
worst  pitfalls  associated  with  "borrowing"  a  tool  from  an  acquaintance  or 
procuring  one  from  the  most  accessible  or  persuasive  tool  vendor. 

2.  The  assignment  and  training  of  a  toolsmlth  who  can  make  minor  modifications 
to  both  the  computer  environment  and  the  tool.  This  Is  expected  to  provide 
relief  where  there  are  version-related  or  release-related  Incompatibilities 
with  the  operating  system,  or  where  the  memory  requirements  of  the  tool 
exceed  the  capabilities  of  the  Installation,  In  the  latter  case,  remedies 
may  be  provided  by  removing  tool  options  or  by  structuring  the  tool  program 
I nto  over  I  ays. 
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The  event  sequence  described  below  Is  conceived  as  a  procedure  generally 
applicable  to  tl^e  introduction  of  tools  to  Federal  agencies  falling  into 
pertinent  programming  environment  categories.  For  this  reason,  a  systematic 
reporting  of  the  experience  with  the  Introduction  process  as  well  as  with  the 
tool  is  desirable.  The  evaluation  plan  and  the  evaluation  report  specified  in 
the  event  sequence  support  these  goals. 


5.2    RECOMMENDED  EVENT  SEQUENCE 

The  event  sequence  described  in  this  subsection  is  applicable  to  both  the 
smaller  MIS  and  scientific  programming  environments.  The  general  scope  of  the 
introduction  activities  and  their  sequence  are  identical  for  the  two 
environments.  Because  of  differences  In  tool  requirements,  personnel 
qualifications,  and  organizational  structure,  some  differences  In  the  content  of 
the  Individual  events  will  be  expected.  The  event  sequence  addresses  only  the 
Introduction  of  existing  tools.  Where  a  newly  developed  tool  Is  Introduced,  a 
considerable  modification  of  the  activities  and  their  sequence  will  be 
necessary. 

The  recommended  event  sequence  allows  for  two  procurement  methods:  Informal 
procurement  (e.  g.,  by  purchase  order)  or  formal  procurement  by  request  for 
bids.  Obviously,  the  latter  Is  much  more  time  consuming  but  It  may  lead  to  the 
procurement  of  better  or  cheaper  tools.  Acquisition  of  tools  from  the  General 
Services  Administration  or  from  other  Government  agencies  should  follow  the 
Informal  procurement  steps  even  when  there  Is  no  procedural  requirement  for 
this.  As  mentioned  above,  tool  acquisitions  which  do  not  obtain  the  concurrence 
of  all  affected  operational  elements  frequently  do  not  achieve  their  objectives. 

The  presentation  of  the  event  sequence  In  Table  5-1  Is  tailored  to  tools  which 
are  being  Introduced  for  the  first  time  Into  a  user  community  which  shares 
software  support  information  (e.  g.,  a  Federal  agency  or  a  private  sector 
company).  As  a  result,  some  steps  are  shown  which  can  be  combined  or  eliminated 
where  less  formal  control  Is  exercised  or  where  plans  or  modifications  required 
for  the  introduction  of  a  tool  are  available  from  a  prior  user.  The  event 
sequence  Is  Intended  to  cover  a  wide  range  of  applications,  and  it  was 
constructed  with  the  thought  that  It  Is  easier  for  the  tool  user  to  eliminate 
steps  than  to  be  confronted  with  the  need  for  adding  some  that  had  not  been 
covered  In  this  volume. 

The  key  functions  which  contribute  to  the  Introduction  of  tools  are  listed 
across  the  top  of  Table  5-1,  and  events  for  which  each  function  Is  responsible 
are  listed  In  the  column  under  It.  The  preferred  order  of  tasks  for  each 
function  can  thus  be  directly  found  from  this  table.  The  precedence 
relationships  between  events  Is  shown  In  graph  form  In  Figure  5-1.  This  figure 
will  be  found  particularly  helpful  for  scheduling  activities  by  the  Critical 
Path  Method  and  for  the  general  development  of  a  project  schedule.  The 
numbering  of  events  Is  the  same  In  Table  5-1  and  Figure  5-1.  A  detailed 
description  of  each  of  the  numbered  events,  and  of  the  activities  associated 
with  It,  Is  presented  following  the  table  and  figure. 
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TABLE  5  -  1      EVENT  SEQUENCE  FOR  TOOL  INTRODUCTION 


FUNDING 
MANAGEMENT 

SOFTWARE 
MANAGEMENT 

SOFTWARE 
ENGINEER 

TOOL 
USER 

1 .  Goa I s 

2.  Tool  Objectives 

3.  Procure  tool 
7,  Receive  tool 

A  <  

14.    Goals  met? 

A  <  

A  <  

A  <  

9.  Orientation 
  A  <  

—  4.  Eval uatlon  pi  an 

—  5.  Tool  smithing  plan-S 

—  6.  Tralnl ng  p 1  an  

8.  Acceptance  test 

10.  Modi  float I ons-S 

<  1 1  ,  Train 

—  13.  Evaluation  report 

-  participates 

ing  > 

12.  Use 

A. 

Acquisition  Activities  for  Informal  Procurement 

A  <  

A1 .  Acquisition  plan 
A2.  Select'n  criteria 

A6.  Select  tool 

continue  wit 

A3.  Ident.  candidates 
A5.  Score  candidates 

h  step  3  above. 

A4 .  Rev  i  ew 

E 

Acquisition  Activities  for  Formal  Procurement 

A  <—  

A  <  

B5.  Issue  RFP 

B1  .  AcquI sltion  pi  an 

„  A  <  

B7,  Select  source 

cont  i  nue  w  i  t 

B2.  Technical  req'mts 
-  B4.  Generate  RFP 

B6.  Proposal  Evaluation 

h  step  3  above. 

B3.  Review 

A  =  Approval  required                 S  =  Toolsmith  responsibility 
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1 .  Goals 

The  goals  to  be  accomplished  should  be  Identified  In  a  format  that  permits  later 
determination  (event  14)  that  they  have  been  met.  Typical  goal  statements  are: 
reduce  average  processing  time  of  COBOL  programs  by  one-fifth;  achieve  complete 
Interchangeabl I Ity  of  programs  or  data  sets  with  organization  Y;  adhere  to  an 
established  standard  for  documentation  format. 

The  statement  of  goals  shall  also  Identify  responsibilities.  In  particular  the 
role  that  headquarters  staff  organization  may  have  and  coordination  requirements 
with  other  organizations.  Where  a  decentralized  management  method  is  employed- 
the  statement  of  goals  may  have  associated  with  it  a  not-to-exceed  budget  and  a 
desired  completion  date.  Once  these  constraints  are  specified,  funding 
management  may  delegate  the  approval  of  the  acquisition  plan  to  a  lower  level. 

2.  Tool  Objectives 

The  goals  generated  in  event  1  are  translated  into  desired  tool  features  (e.g., 
see  TabI e  4-1 ) ,  and  requirements  arising  from  the  development  and  operating 
environment  are  Identified.  Constraints  on  tool  cost  end  availability  may  also 
be  added  at  this  event.  A  typical  statement  of  tool  objectives  for  a  program 
formatter  Is:  Provide  header  Identification,  uniform  Indentation,  and  the 
facility  of  printing  listing  and  comments  separately  for  all  FORTRAN  X3.9-1978 
and  ABC  Extended  FORTRAN  programs.  Program  must  run  on  our  ABC  computer  under 
XOSnn.  Only  tools  which  have  been  In  commercial  use  for  at  least  1  year  and  at 
no  less  than  N  different  sites  shall  be  considered. 

At  this  point  the  sequence  continues  with  either  A1  or  B1  below. 


A,    Acquisition  Activities  for  Informal  Procurement 
A1 ,    Acquisition  Plan 

The  acquisition  plan  communicates  the  actions  of  software  management  both  upward 
and  downward.  The  plan  may  also  be  combined  with  the  statement  of  the  tool 
objectives  (event  2).  The  acquisition  plan  should  Include  the  budgets  and 
schedules  for  subsequent  steps  In  the  tool  introduction,  a  justification  of 
resource  requirements  In  the  light  of  expected  benefits,  contributions  to  the 
Introduction  expected  from  other  organizations  (e.  g.,  the  tool  Itself, 
modification  patches,  or  training  materials),  and  the  assignment  of 
responsibility  for  subsequent  events  within  the  software  organization, 
particularly  the  Identification  of  the  software  engineer.  Minimum  tool 
documentation  requirements  shall  also  be  specified  In  the  plan. 

A2.    Selection  Criteria 

The  criteria  shall  Include  a  ranked  or  weighted  listing  of  attributes  ihat  will 
support  effective  utilization  of  the  tool  by  the  user.  Typical  selection 
criteria  are: 
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Accomplishment  of  specified  tool  objectives. 

Ease  of  use. 

Ease  of  Installation. 

Minimum  processing  time. 

Compatibility  with  other  tools. 

Low  purchase  or  lease  cost. 

Most  of  these  criteria  need  to  be  factored  further  to  permit  objective 
evaluation,  but  this  step  may  be  left  up  to  the  Individual  who  does  the  scoring. 
Together  with  the  criteria  (most  of  which  will  normally  be  capable  of  a  scalar 
evaluation),  constraints  which  have  been  imposed  by  the  preceding  events  or  are 
generated  at  this  step  should  be  summarized. 

A3.     Identify  Candidate  Tools 

This  Is  the  first  event  for  which  the  software  engineer  Is  responsible.  The 
starting  point  for  preparing  a  listing  of  candidate  tools  Is  a  comprehensive 
tool  catalogue,  such  as  IIH0UG82].  A  desirable  but  not  mandatory  practice  is  to 
prepare  two  lists,  the  first  of  which  does  not  consider  the  constraints  and 
contains  all  tools  meeting  the  functional  requirements.  The  Cross-Ref erence  by 
tool  features  In  the  appendices  of  CH0UG82I]  will  be  found  particularly  valuable 
In  generating  this  list  of  candidates.  For  the  example  used  In  event  2,  a 
program  formatting  tool,  16  entries  are  found  there.  Some  of  these  may  be 
eliminated  by  further  review  of  their  description  In  the  body  of  the  catalogue 
(e.  g.,  because  they  don't  process  the  specified  FORTRAN  dialects).  For  the 
remaining  viable  candidates,  literature  should  be  requested  from  the  developer, 
and  this  Is  examined  for  conformance  with  the  given  constraints.  At  this  point 
a  second  list  Is  generated,  containing  tools  that  meet  both  the  functional 
requirements  and  the  constraints.  If  this  list  does  not  have  an  adequate  number 
of  entries,  relaxation  of  some  constraints  will  have  to  be  considered, 

A4.    User  Review  of  Candidates 

The  user  reviews  the  list  of  candidate  tools  prepared  by  the  software  engineer. 
Because  few  users  can  be  expected  to  be  very  knowledgeable  In  the  software  tools 
area,  specific  questions  may  need  to  be  raised  by  software  management  such  as: 
"Will  this  tool  handle  the  present  file  format?  Are  tool  commands  consistent 
with  those  of  the  editor?  How  much  training  will  be  required?"  Adequate  time 
should  be  budgeted  for  this  review  and  a  due  date  for  responses  should  be 
Indicated.  Because  the  user  views  this  as  a  far-term  task,  of  lower  priority 
than  many  Immediate  obligations,  considerable  follow-up  by  line  management  will 
be  required.  If  tools  can  be  obtained  for  trial  use,  or  If  a  demonstration  at 
another  facility  can  be  arranged.  It  will  make  this  step  much  more  significant. 

A5 .    Score  Candidates 

For  each  of  the  criteria  previously  Identified  a  numerical  score  Is  generated 
on  the  basis  of  Information  obtained  from  vendor's  literature,  from 
demonstration  of  the  tool,  from  the  user's  review,  from  observation  In  a  working 
environment,  or  from  comments  of  prior  users.  If  weighting  factors  for  the 
criteria  are  specified,  the  score  for  each  criterion  Is  multiplied  by  the 
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appropriate  factor  and  the  sum  of  the  products  represents  the  overall  tool 
score.  Where  only  a  ranking  of  the  criteria  was  provided,  the  outcome  of  the 
scoring  may  be  simply  a  ranking  of  each  candidate  under  each  of  the  criteria 
headings.  Frequently  a  single  tool  Is  recognized  as  clearly  superior  In  this 
process, 

A6.  Select  Tool 

This  decision  Is  reserved  for  software  management  In  order  to  provide  review  of 
the  scoring,  and  also  to  permit  additional  factors  which  were  not  expressed  in 
the  criteria  to  be  taken  Into  consideration.  For  example,  a  report  might  just 
have  been  received  from  another  agency  that  the  selected  vendor  did  not  provide 
adequate  service.  If  the  selected  tool  was  not  scored  highest,  the  software 
engineer  should  have  an  opportunity  to  review  the  tool  characteristics 
thoroughly  to  avoid  unexpected  Installation  difficulties.  The  selection 
concludes  the  separate  sequence  for  Informal  procurement.  Continue  with  event 
3. 


 Acquisition  Activities  for  Formal  Procurement 

Bl ,    Acquisition  Plan 

The  plan  generated  here  must  Include  all  elements  mentioned  under  A1  plus  the 
constraints  on  the  procurement  process  (e,  g,,  set-aside  for  high  labor  surplus 
areas)  and  the  detailed  responsibilities  for  all  procurement  documents 
(statement  of  work,  technical  and  administrative  provisions  In  the  Request  for 
Proposa I ,  etc , ) , 

62,    Technical  Requirements  Document 

The  technical  requirements  document  Is  an  Informal  description  of  the  tool 
requirements  and  the  constraints  under  which  the  tool  has  to  operate.  It  will 
utilize  much  of  the  material  from  the  acquisition  plan  but  should  add  enough 
detail  to  support  a  meaningful  review  by  the  tool  user, 

B3,    User  Review  of  Requirements 

The  user  reviews  the  technical  requirements  for  the  proposed  procurement.  As  In 
the  case  of  event  A4,  the  user  may  need  to  be  prompted  with  pertinent  questions, 
and  there  should  be  close  management  follow  up  In  order  to  get  a  timely 
response, 

84,    RFP  Generation 

From  the  technical  requirements  document  and  the  user  comments  on  It,  the 
technical  portions  of  the  RFP  can  be  generated.    Usually  these  Include: 

1,  A  specification  of  the  tool  as  delivered.  This  should  Include 
applicable  documents,  a  definition  of  the  operating  environment,  and 
the  quality  assurance  provisions. 
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2.  A  statement  of  work  governing  the  tool  procurement.  This  should 
state  any  applicable  standards  for  the  process  by  which  the  tool  Is 
generated  (e.  g.,  configuration  management  of  the  tool),  and 
documentation  or  test  reports  to  be  furnished  with  the  tool. 
Training  and  operational  support  requirements  are  also  identified  in 
the  statement  of  work. 

3.  Proposal  evaluation  criteria  and  format  requirements.  Evaluation 
criteria  are  listed  In  the  approximate  order  of  Importance. 
Subfactors  for  each  may  be  Identified.  Restrictions  on  proposal 
format  (major  headings,  page  count,  desired  sample  outputs)  may  also 
be  included. 

B5.    Solicitation  of  Proposals 

This  activity  is  carried  out  by  administrative  personnel.  Capability  lists  of 
potential  sources  are  maintained  by  most  purchasing  organizations.  Where  the 
software  organization  knows  of  potential  bidders,  their  names  should  be  made 
known  to  the  procurement  office.  When  responses  are  received,  they  are  screened 
for  compliance  with  major  legal  provisions  of  the  RFP. 

B6.    Technical  Evaluation 

Each  of  the  proposals  received  in  response  to  the  RFP  is  evaluated  against  the 
criteria  previously  established.  Failure  to  meet  major  technical  requirements 
can  lead  to  outright  disqualification  of  a  proposal.  Those  deemed  to  be  in  "the 
competitive  range"  will  be  assigned  point  scores  that  will  then  be  used  together 
with  cost  and  schedule  factors  that  are  being  separately  evaluated  by 
administrative  personnel. 

B7 .    Source  Selection 

On  the  basis  of  the  combined  cost,  schedule,  and  technical  factors,  a  source  for 

the  tool  Is  selected.     If  this  was  not  the  highest  rated  technical  proposal, 

prudent  management  will  require  additional  reviews  by  software  management  and 

the  software  engineer  to  determine  that  it  Is  Indeed  acceptable. 

The  source  selection  concludes  the  separate  sequence  for  formal  procurement. 
Continue  with  event  3. 


3.    Procure  Tool 

In  addition  to  determining  that  the  cost  of  the  selected  tool  Is  within  the 
approved  budget,  the  procurement  process  will  also  consider  the  adequacy  of 
licensing  and  other  contractual  provisions  and  compliance  with  the  "fine  print" 
associated  with  all  Government  procurements.  The  vendor's  responsibility  for 
furnishing  the  source  program,  for  meeting  specific  test  and  performance 
requirements,  and  for  tool  maintenance  need  to  be  identified.  In  Informal 
procurement,  a  period  of  trial  use  may  be  considered  if  this  had  not  already 
taken  place  under  one  of  the  previous  events. 
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If  the  acquisition  plan  Indicates  the  need  for  outside  training,  the  ability  of 
the  vendor  to  supply  the  training  and  the  cost  advantages  from  combined 
procurement  of  tool  and  training  should  be  Investigated.  If  substantial  savings 
can  be  realized  through  simultaneous  purchase  of  tool  and  training,  procurement 
may  be  held  up  until  outside  training  requirements  are  defined  (event  6). 

4.  EvaluatlQP  Plan 

The  evaluation  plan  Is  based  on  the  goals  Identified  In  event  1  and  the  tool 
obectlves  derived  from  these  In  event  2.  It  describes  how  the  attainment  of 
these  objectives  Is  to  be  evaluated  for  the  specific  tool  selected.  Typical 
Items  to  be  covered  In  the  plan  are  milestones  for  Installation,  dates  and 
performance  levels  for  the  Initial  operational  capability  and  for  subsequent 
enhancements.  Where  Improvements  In  throughput,  response  time,  or  turn-around 
time  are  expected,  the  reports  from  which  these  data  are  to  be  obtained  should 
be  Identified,  Responsibility  for  tests,  reports  and  other  actions  should  be 
assigned  In  the  plan.  A  topical  outline  of  the  Evaluation  Report  should  be 
I ncl uded. 

The  procedure  for  the  acceptance  test  Is  a  part  of  the  Evaluation  Plan,  although 
In  a  major  tool  procurement  It  may  be  a  separate  document.  It  lists  the 
detailed  steps  necessary  to  test  the  tool  In  accordance  with  the  procurement 
provisions  when  It  is  received,  to  evaluate  the  Interaction  of  the  tool  with  the 
computer  environment  (e.  g.,  adverse  effects  on  throughput),  and  for  generating 
an  acceptance  report, 

5.  Toolsmlthlng  Plan 

The  plan  will  describe  the  selection  of  the  toolsmlth,  the  responsibilities  for 
the  adaptation  of  the  tool,  and  the  training  which  will  be  required.  The 
toolsmlth  should  preferably  be  an  experienced  system  programmer,  familiar  with 
the  current  operating  system.  Training  In  the  operation  and  Installation  of  the 
selected  tool  In  the  form  of  review  of  documentation,  visits  to  current  users  of 
the  tool,  or  training  by  the  vendor  must  be  arranged.  The  toolsmlthlng  plan  Is 
listed  here  as  an  event  for  which  the  software  engineer  Is  responsible,  and  In 
the  discussion  of  further  events  It  Is  assumed  that  the  toolsmlth  will  work 
under  the  direction  of  the  software  engineer.  The  toolsmlthlng  plan  should  be 
approved  by  software  management. 

6.  Training  Plan 

The  training  plan  should  first  consider  the  training  Inherently  provided  with 
the  tool,  e,  g,,  documentation,  test  cases,  on-line  diagnostics,  HELP.  These 
features  may  be  supplemented  by  standard  training  aids  supplied  by  the  vendor 
for  In-house  training  such  as  audio  or  video  cassettes  and  lecturers.  Because 
of  the  expense,  training  sessions  at  other  locations  should  be  considered  only 
where  none  of  the  previous  categories  Is  available.  The  number  of  personnel  to 
receive  formal  training  should  also  be  specified  In  the  plan,  and  adequacy  of 
In-house  facilities  (number  of  terminals,  computer  time,  etc.)  should  be 
addressed.  If  training  by  the  tool  vendor  Is  desired,  this  should  be  Identified 
as  early  as  possible  to  take  permit  training  to  be  procured  with  the  tool  (see 
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step  3).  User  Involvement  In  the  preparation  of  the  training  plan  Is  highly 
desirable,  and  coordination  with  the  user  Is  considered  essential.  The  training 
plan  Is  normally  prepared  by  the  software  engineer  and  approved  by  software 
management.  Portions  of  the  plan  should  be  furnished  to  procurement  staff  If 
outside  personnel  or  facilities  are  to  be  utilized. 

7.  Tool  Received 

The  tool  is  turned  over  by  the  procuring  organization  to  the  software  engineer. 

8.  Acceptance  Test 

The  software  engineer  or  staff  test  the  tool.    This  is  done  as  much  as  possible 
In  an  "as  received"  condition  with  only  those  modifications  made  that  are 
essential  for  bringing  it  up  on  the  host  computer.  A  report  on  the  test  Is 
issued.    After  approval  by  software  management  it  constitutes  the  official 
acceptance  of  the  tool. 

9.  Qri^ntation 

When  it  has  been  determined  that  the  tool  has  been  received  in  a  satisfactory 
condition,  software  management  holds  an  orientation  meeting  for  all  personnel 
Involved  In  the  use  of  the  tool  and  tool  products  (reports  or  listings  generated 
by  the  tool).  The  main  purpose  Is  to  communicate  as  directly  as  possible  the 
objectives  of  the  tool  use,  such  as  increased  throughput  or  Improved  legibility 
of  listings.  Highlights  of  the  evaluation  plan  should  also  be  presented,  and 
any  changes  In  duties  associated  with  the  introduction  of  the  tool  should  be 
described.  Personnel  should  be  reassured  that  allowance  will  be  made  for 
problems  encountered  during  the  Introduction,  and  that  the  full  benefits  of  the 
tool  may  not  make  themselves  felt  for  some  time. 

10.  Modifications 

This  step  Is  carried  out  by  the  toolsmlth  In  accordance  with  the  approved 
toolsmlthing  plan.  It  includes  modifications  of  the  tool  Itself,  of  the 
documentation,  and  of  the  operating  system.  In  rare  cases  some  modification  of 
the  computer  proper  may  also  be  necessary  (channel  assignments,  etc.).  Typical 
tool  modifications  involve  deletion  of  unused  options,  changes  in  prompts  or 
diagnostics,  and  other  adaptations  made  for  efficient  use  in  the  prevailing 
environment.  Documentation  of  the  modifications  Is  an  essential  part  of  this 
event. 

Vendor  literature  for  the  tool  Is  reviewed  In  detail  and  Is  tailored  for  the 
prevailing  computer  environment  and  for  the  tool  modifications  which  have  been 
made.  Deleting  sections  which  are  not  applicable  can  be  Just  as  useful  as 
adding  material  that  Is  required  for  the  specific  programming  environment. 
Unused  options  shall  be  clearly  marked  or  removed  from  the  manuals.  If  there  Is 
some  resident  software  for  which  the  tool  should  not  be  used  (e.  g.,  because  of 
language  Incompatibility  or  conflicts  In  the  operating  system  interface), 
warning  notices  should  be  inserted  into  the  tool  manual. 
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1 1 .  Tra I n I ng 

Training  Is  a  joint  responsibility  of  the  software  engineer  and  the  tool  user. 
The  former  Is  responsible  for  the  content  (In  accordance  with  the  approved 
training  plan),  and  the  latter  should  have  control  over  the  length  and 
scheduling  of  sessions.  Training  Is  an  excellent  opportunity  to  motivate  the 
user  to  utilize  the  tool.  The  tool  user  should  have  the  privilege  of 
terminating  steps  In  the  training  that  are  not  helpful  and  of  extending  portions 
that  are  helpful  but  In  which  greater  depth  Is  desired.  Training  Is  not  a 
one-time  activity.  Retraining  or  training  in  the  use  of  additional  options 
after  the  Introductory  period  Is  desirable.  This  also  provides  an  opportunity 
for  users  to  talk  about  problems  with  the  tool. 

12.  Use  In  the  Operating  Environment 

The  first  use  of  the  tool  In  the  operational  environment  should  Involve  the  most 
qualified  user  personnel  and  minimal  use  of  options.  The  first  use  should  not 
be  on  a  project  with  tight  schedule  constraints.  Any  difficulties  resulting 
from  this  use  must  be  resolved  before  expanded  service  is  initiated.  If  the 
first  use  is  successful,  then  use  by  additional  personnel  and  use  of  further 
options  may  commence. 

User  comments  on  training,  first  use  of  the  tool,  and  use  of  extended 
capabilities  are  prepared  and  furnished  to  the  software  engineer.  Desired 
improvements  In  the  user  Interface,  speed  or  format  of  response,  and  in 
utilization  of  computer  resources  are  appropriate  topics.  Formal  comments  may 
be  solicited  shortly  after  the  Initial  use,  after  6  months,  and  again  after  1 
year. 

13.  Evaluation  Report 

The  soft-ware  engineer  prepares  the  Evaluation  Report,  using  the  outline 
generated  In  event  4.  The  user  comments  and  observations  of  the  tool  smith  form 
important  inputs  to  this  document.  Most  of  all.  It  must  discuss  how  the  general 
goals  and  the  tool  objectives  were  met.  The  report  may  Include,  of  course, 
observations  on  the  Installation  and  use  of  the  tool,  cooperation  received  from 
the  vendor  in  installation  or  training,  and  any  other  "lessons  learned".  Tool 
and  host  computer  modifications  shall  be  described  In  the  report.  It  may 
contain  a  section  of  comments  useful  to  future  users  of  the  tool.  The  report  Is 
approved  by  software  management  and  preferably  also  by  funding  management, 

14.  Determine  If  Goals  Are  Met 

Funding  management  receives  the  Evaluation  Report  and  determines  whether  the 
goals  established  In  event  1  have  been  met.  This  determination  shal  I  be  In 
writing  and  It  shall  Include: 

Attainment  of  technical  objectives. 

Adherence  to  budget  and  other  resource  constraints. 

Timeliness  of  the  effort. 

Cooperation  from  other  agencies. 

Recommendations  for  future  tool  acquisitions. 
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APPENDIX 

WORKSHOP  ON  PHASING  OF  SOFTWARE  TOOLS 
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Lecture  Room  B,  Administration  Building 
Monday,  18  May  1981 


AGENDA 


0900  -  0930         Welcome  to  NBS 

0930  ~  1000        Software  Automation  Project  and 

Objectives  of  the  Workshop 

1000  -  1015        Coffee  Break 

1015  -  1100        Survey  of  Software  Tool  Usage 

1100  -  1215        Tools  Introduction  Experience 

NASA  Lang  ley 

Naval  Air  Development  Center 
NASA  Goddard 


M.  Branstad,  NBS 
R.  C.  Houghton,  NBS 

H.  Hecht,  SoHaR 


S.  Volgt 
H.  Stuebing 
F.  McGarry 


1215  -  1313 


Lunch 


1315  -  1400        Guidelines  for  Phasing  Software  Tools 

Into  Development  Environments 


1400  - 

1445 

Discussion  Groups 

1445  - 

1500 

Coffee  Break 

1500  - 

1545 

Event  Sequence  for  Tool  Introduction 

1545  - 

1630 

Discussion  Groups 

1630  - 

1700 

Wrap-Up 

H.  Hecht,  SoHaR 


H.  Hecht,  SoHaR 


WORKSHOP  ON  PHASING  OF  SOFTWARE  TOOLS 
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environmental  functions  and  the  durability  and  safety  charac- 
teristics of  building  elements  and  systems. 

Technical  Notes — Studies  or  reports  which  are  complete  in  them- 
selves but  restrictive  in  their  treatment  of  a  subject.  Analogous  to 
monographs  but  not  so  comprehensive  in  scope  or  definitive  in 
treatment  of  the  subject  area.  Often  serve  as  a  vehicle  for  final 
reports  of  work  performed  at  NBS  under  the  sponsorship  of  other 
government  agencies. 

Voluntary  Product  Standards — Developed  under  procedures 
published  by  the  Department  of  Commerce  in  Part  10,  Title  15,  of 
the  Code  of  Federal  Regulations.  The  standards  establish 
nationally  recognized  requirements  for  products,  and  provide  all 
concerned  interests  with  a  basis  for  common  understanding  of  the 
characteristics  of  the  products.  NBS  administer.s  this  program  as  a 
supplement  to  the  activities  of  the  private  sector  standardizing 
organizations. 

Consumer  Information  Series — Practical  information,  based  on 
NBS  research  and  experience,  covering  areas  of  interest  to  the  con- 
sumer. Easily  understandable  language  and  illustrations  provide 
useful  background  knowledge  for  shopping  in  today's  tech- 
nological marketplace. 

Order  the  above  NBS  publications  from:  Superintendent  oj  Docu- 
ments. Government  Printing  Office.  Washington.  DC  20402. 
Order  the  following  NBS  publications — FIPS  and  NBSIR's—Jrom 
the  National  Technical  Information  Services.  Springfield.  VA  22161 . 

Federal  Information  Processing  Standards  Publications  (FIPS 
PUB) — Publications  in  this  series  collectively  constitute  the 
Federal  Information  Processing  Standards  Register.  The  Register 
serves  as  the  official  source  of  information  in  the  Federal  Govern- 
ment regarding  standards  issued  by  NBS  pursuant  to  the  Federal 
Properly  and  Administrative  Services  Act  of  1949  as  amended. 
Public  Law  89-306  (79  Stat.  1127),  and  as  implemented  by  Ex- 
ecutive Order  1  1717  (38  FR  12315,  dated  May  II,  1973)  and  Pari  6 
of  Title  15  CFR  (Code  of  Federal  Regulations). 

NBS  Interagency  Reports  (NBSIR) — A  special  series  of  interim  or 
final  reports  on  work  performed  by  NBS  for  outside  sponsors 
(both  government  and  non-government),  in  general,  initial  dis- 
tribution is  handled  by  the  sponsor;  public  distribution  is  by  the 
National  Technical  information  Services,  Springfield,  VA  22161, 
in  paper  copy  or  microfiche  form. 
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